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 Team Drive prevents this problem, since files in a Team 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 Team Drives
Team Drives provide a shared space in a Google Drive where teams can more effectively collaborate. Files placed in a Team Drive are owned by the team, rather than individuals. This means that when a team member leaves the team they do not take file ownership and control with them.
Team Drives also allow you to move files across domains — a Team Drive in one domain can have collaborators from another domain who can move files from that domain into the Team 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 Team Drives to collaborate on Apps Script projects, keep the following in mind:
- Team members with editor access to a Team Drive are able to create or move new files into the Team Drive. As script editors, they can view and edit scripts projects, run script code, create new script versions, publish add-ons, and deploy scripts as web apps or executables for the Apps Script API.
- Team Drives also let you share specific files within the Team Drive to others outside the team, 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 Team Drive belongs to, you cannot reduce their access for specific files. For example, if a user has edit access to a Team Drive, you can't change that to view-only access for a specific file within the Team Drive.
- Team members with full access to a Team Drive, in addition to the above, are able to delete files and Apps Script projects, and move files out of the Team 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 Team Drive grants the Team Drive's collaborators the same access to the script code as they have for the container itself.
- When a script project resides in a Team Drive, access to its Cloud Platform project may be restricted. See the Cloud projects and Team Drives guide section for details. When collaborating on script projects in Team Drives, you may need to switch to a standard Cloud Platform project.
- Web apps deployed in one domain cease to function if their ownership changes to a Team Drive or account in a different domain. This can be corrected by moving the script back to its original domain, or having a collaborator redeploy the script project in the new domain.
- Similarly, script projects that are deployed as an Apps Script API executable cease to function when called by the API if moved via Team Drives from one domain to another. This can be corrected by moving the script back to its original domain, or having a collaborator redeploy the script project in the new 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 Team 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.
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 project. Cloud Platform 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.
When you collaborate on a script project, we recommended that you configure the Cloud Platform 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.