Building Editor add-ons (original) (raw)

Building Editor add-ons

Stay organized with collections Save and categorize content based on your preferences.

Before building your Editor add-on, review theApps Script quotas and limitations to ensure your project design aligns with these guidelines. Familiarizing yourself with these limits early in your development process can help prevent potential issues later on. Apps Script is ideal for lightweight add-on development for yourself, your team, or your organization. However, if you anticipate building a large-scale add-on that needs to handle many users, requires low latency, or demands full control over your infrastructure, consider developing a Google Workspace add-on on adifferent runtime environment.

Follow this general procedure when building an Editor add-on:

  1. Create an Apps Script project.
  2. Write code to define the add-on's appearance and behavior, using the built-in Apps Script HTML service.
  3. Test the add-on.
  4. Publish the add-on.

Create a script project

An Editor add-on is a standalone Apps Script project. The standalone script guide providesinstructions to create new projects. You can also justopen a new script. If you do this, the project file (initially named Untitled project) is placed in your root Drive folder.

Collaboration

When you collaborate with others in developing an add-on, a single user account owns the add-on project. When you publish an add-on, a single user account acts as the publisher. The publishing account must have edit access to the add-on script project, but it doesn't need to be project owner.

It's very important to avoid situations where you lose access to an add-on's code or settings because the owner of the project left your organization.

To prevent losing access to add-on code, we encourage you to useshared driveswhen you collaborate on an add-on. Placing your add-on script file in a shared drive ensures that no single account is the sole owner of the project.

It is also recommended that youadd collaborators to the script project's Cloud Platform (GCP) project. This helps ensure someone on your team always can access the add-on's Cloud settings.

Code the add-on

Once you have created a script project, you can begin writing code to define the add-on appearance and behavior. You use the Apps ScriptHtmlService to construct the add-on user interface—dialogs and sidebars— using conventional HTML and CSS. Editor add-ons can define custommenu items as well.

As you code, refer to the Editor add-on style guidefor guidelines on how to design your add-on user experience. Also, be sure you understand and program for the differentauthorization lifecycle statesyour add-on can encounter.

Test the add-on

You can test Editor add-ons before they are published to ensure they behave as expected. Testing requires you to create atest configurationand use a testing document, spreadsheet, form, or presentation.

See Test an Editor add-onfor details.

Publish the add-on

Publishing your add-on makes it available to others, either publicly or just users in your domain. Before you start the publishing process, be sure to review the publication overview.

Editor add-ons are published to the Google Workspace Marketplace. Publicly available add-ons must complete add-on review before they are published.

See Publishing an Editor add-onfor more details.