Why you should share your Apps Script projects as G Suite Add-ons
Charles Maxson
Developer Advocate, G Suite
Developing your Apps Script project as a G Suite Add-on makes your code more portable and lets you use it over and over again just as if it were built into G Suite.
Try Google Workspace at No Cost
Get a business email, all the storage you need, video conferencing, and more.
SIGN UPApps Script is a great way to quickly create automations and utilities to speed up processes or eliminate repetitive tasks within G Suite. Once you’ve developed such a tool, you’ll probably want to share it with colleagues across your organization. Sharing the Sheet or Doc that’s bound to your script project is simple and intuitive, as a cornerstone of G Suite is friction-free collaboration.
But why not share your project as a G Suite Add-on? With just a few extra steps, you can enable others to discover your app and avoid some of the pitfalls of basic document sharing—and do so in a scalable, more manageable way.
About Add-ons
G Suite Add-ons, as the name suggests, enable solution developers to add new functionality and features to G Suite or to integrate their own third-party solutions with the product. If you’re successfully writing Apps Script projects and sharing them with others, you’ve probably heard of Add-ons—and might have used a few yourself (here’s a little more information if you haven’t).
Google partners including Lucidchart, DocuSign, Smartsheet, and many other third-party developers already offer Add-ons through the G Suite Marketplace, where users and G Suite admins can discover and deploy extensions for G Suite.
The case for creating Add-ons
If you’re like most folks using Apps Script to automate G Suite, you’re probably not in the business of building solutions for the world; you’re most likely more focused on developing useful tools for yourself, your team, and the rest of your company. You might never have considered creating an add-on, likely because you thought it was not suited for small projects meant to be shared privately among just your work group.
The reality is that developing your Apps Script project as an add-on has benefits even if you’re the only one who will ever use it. For starters, it makes your code more portable by unlocking it from being bound to a single document. This lets you use it over and over again with different documents, with little effort; just as if it were built into G Suite.
Here’s an example from my own experience with Add-ons. I wrote a number of Apps Script automations to make managing notes in Google Slides easier, such as clearing them, changing formatting, and exporting notes into a new Doc, among other things.
I originally created these tools for one presentation that I used a lot, but once I realized how useful they were, I found myself copying the code from that project to new code projects bound to other Slides presentations—over and over again. After a while, I realized I was repeating work unnecessarily—and detracting from the efficiency gains my utility offered. So I prepared my utility as an add-on, published it to my organization's domain, and now I can use it instantly with every new slide deck I work with going forward.
Another advantage is once your add-on is published to the domain, anyone else in your organization can discover it by browsing the G Suite Marketplace for your domain add-ons, and deploy it—all without having to connect with you or even know you! On top of that, add-ons that have mass appeal for your organization can be deployed directly to the whole org (or specific domain organizational units) by your G Suite administrator, making broad distribution seamless and standard.
Building your own Add-ons
Hopefully you now have a clearer picture of the benefits of deploying your solutions as add-ons; it really isn’t much more work to go from a simple, document-bound project to a ready-to-share add-on. For one thing, you’ll want to make sure your user interface (menus, sidebars, dialogs) is as intuitive as possible, as others will be discovering and using your add-on without your guidance. You’ll need to leverage add-on specific events such as the onInstall trigger that will run your code when it's installed directly from one of the G Suite editor apps. Then of course, when you’ve got your code written and tested, you publish your add-on according to the steps outlined here.
And that’s about it!
Please note that in the post we have been primarily referring to Editor-based add-ons, which pertain to Sheets, Docs, Slides, and Forms. There is a newer G Suite Add-ons framework that spans all of G Suite you can use alternatively; I’ll discuss this in an upcoming post.
Here are some resources to help you learn more about both methods for creating add-ons for G Suite:
