Apps Script provides some features that help you and other developers to build and maintain scripts, add-ons, and web apps together.
In order to collaborate on a project, you and your collaborators must all have editor access to the Apps Script project file (and its container, if it is a bound script). This lets everyone on your team see and make changes to the Apps Script code. Editors can also create new code versions, publish add-ons, and deploy scripts as web apps or as executables for the Apps Script API.
You can help your team by planning beforehand how you handle the editing, reviewing, versioning, and (if applicable) the deployment and publishing of your project, add-on or web app. Standalone projects are usually the easiest to collaborate on, because they appear directly in Google Drive and are the recommended project type for add-on and web app development.
A common problem in collaboration occurs when a script project owner leaves the team without transferring ownership of the project to someone else on the team. This can leave you unable to maintain or update the project. Placing your script project in a shared drive prevents this problem, since files in a shared drive don't have specific owners.
Collaboration with the
clasp command line tool
clasp allows you to sync projects between script.google.com and your local file
system. This allows you to streamline and automate your code development if you
and your collaborators are using source control management software such as
See the Command Line Interface using
for more details.
Collaborating with shared drives
Shared drives (formerly known as "Team Drives") provide a shared space in a Google Drive where groups of Drive users can more effectively collaborate. Files placed in a shared drive are owned by the group as a whole, rather than individuals. This means that when a collaborator leaves the group they do not take file ownership and control with them.
Shared drives also allow you to move files across domains — a shared drive in one domain can have collaborators from another domain who can move files from that domain into the shared drive. This can be very valuable to Apps Script developers, as it provides a means for a team to develop add-ons, web apps, or other code for customers in different domains.
When you use shared drives to collaborate on Apps Script projects, keep the following in mind:
- Collaborators with editor access to a shared drive are able to create or move new files into the shared drive. As script editors, they can view and edit scripts projects, run script code, create new script versions, publish add-ons.
- To deploy scripts as web apps or executables for the Apps Script API, the account that creates the deployment must belong to the same domain as the shared drive that the script resides in.
- Shared drives let you share specific files within the shared drive to others outside the group, and update their edit and view permissions on those files like any other Drive file. However, if a user is part of the team the shared drive belongs to, you cannot reduce their access for specific files. For example, if a user has edit access to a shared drive, you can't change that to view-only access for a specific file within the shared drive.
- Collaborators with full access to a shared drive, in addition to the above, are able to delete files and Apps Script projects, and move files out of the shared drive.
- All container-bound scripts use the same viewer and editor access lists defined for the container file. For example, if you have edit access to a Google Sheet you also have edit access to any Apps Script project code attached to it. Placing such a container file into a shared drive grants the shared drive's collaborators the same access to the script code as they have for the container itself.
- When a script project resides in a shared drive, access to its Cloud Platform (GCP) project may be restricted. See the GCP projects and shared drives guide section for details.
- Web apps deployed in one domain cease to function if their ownership changes to a shared drive or account in a different domain. This can be corrected by moving the script back to its original domain.
- Similarly, script projects that are deployed as an Apps Script API executable cease to function when called by the API if moved via shared drive from one domain to another. This can be corrected by moving the script back to its original domain.
Collaborating with project sharing
You can also collaborate on a project by directly sharing the project with all the collaborators. You can directly share script projects that reside in regular Google Drive folders or in shared drives. If you use this method, it is recommended that you carefully plan who owns and maintains the script over time.
Container-bound projects are not visible from your Google Drive. To share a container-bound project, you simply share the parent container file. For example, if you have a script bound to a Google Sheet, you can make someone an editor of the script by making them an editor of the Google Sheet. The viewer and editor access settings of container file are inherited by all the projects within that container.
All container-bound scripts use the same owner, viewer and editor access list defined for the container file. The container owner takes ownership of a new script project regardless of who created it.
Collaborating and project resources
Resources are entities that are associated with your project but exist independently of its code. This section explains how collaborating on a project affects its resources, in particular: its Cloud Platform project, triggers, libraries, and user properties.
Collaborating and Cloud Platform projects
Every Apps Script project has an associated Cloud Platform (GCP) project. GCP projects have their own set of owners, editors, and other roles, which can be different from the set of users that can access the script project.
If your script project is meant to be published as an add-on, it must use a standard GCP project. When you collaborate on an application that uses a standard GCP project, we recommended that you configure the GCP owners and roles to ensure all your collaborators have the proper levels of access. This helps prevent situations where you lose access to the project's Cloud settings because its owners are no longer with your organization. This is especially important for add-ons.
Collaborating and triggers
When you collaborate on a project, any installable triggers that you create are not shared with those who have access to your project. If you need to have a consistent trigger setup for all collaborators, you can use the Script service to create triggers programmatically, at run time. For more information, see Managing Triggers Programmatically.
Collaborating and libraries
Libraries included in your project are available to project collaborators. However, if they do not have at least read-level access to an included library they can't use those libraries — the script throws an error in this case. For more information about libraries, see Managing Libraries.
Collaborating and user properties
User properties are unique to the user that created them. This means that the project collaborators can't see or access your user properties and you can't see or access theirs. Use script properties if you want to share project specific properties with the collaborators. For more information, see the Properties guide.