The 13 sharing and permission settings that make a Google Sheets script work perfectly for you and fail silently for everyone you share it with.
You built a Sheet with an Apps Script that runs beautifully. You share it, and suddenly the buttons do nothing, the onEdit trigger never fires, or the whole thing works only for you. This is almost never a bug in your code. It is a sharing or permission setting deciding who is allowed to run what, and Google’s tighter Workspace defaults have made these traps more common on shared templates. Here are the 13 settings to check, and how to fix each.
In Brief
- Simple triggers like onEdit only run for people who can edit the sheet and who have authorized the script, so viewers and unauthorized editors see nothing happen.
- The reliable fix for shared automations is an installable trigger, because it runs as you, the owner, with your permissions.
- Copied templates lose their triggers, protected ranges block script writes, and Workspace admin policies can disable Apps Script entirely, so check those first when a script fails only for others.
At a Glance
| Setting that blocks the script | The fix |
|---|---|
| Shared as Viewer or Commenter | Grant Editor, or use an installable trigger |
| Script never authorized by the user | Authorize once, or run as owner |
| Simple trigger needs authorization | Switch to an installable trigger |
| Protected range or sheet | Add the running account to its editors |
| Editors can’t change permissions | Turn it off, or share as owner |
| Link sharing set to Restricted | Match the web app’s “Who has access” |
| Web app “Execute as” wrong | Deploy “Execute as me” for templates |
| Copied template lost its triggers | Recreate triggers in the copy |
| Workspace admin restricted Apps Script | Ask the admin to allow it |
| Unverified app warning | Keep it in-domain or verify the app |
| External sharing blocked by policy | Keep the workflow in-domain |
| Shared Drive role too low | Give at least Content manager |
| Download and copy disabled | Re-enable, or export as owner |
Table of Contents
1. Shared as Viewer or Commenter, not Editor
The fix: grant Editor access, or move the logic to an installable trigger that runs as you.
Simple triggers like onEdit and onOpen only fire for a user who can edit the sheet, so a Viewer or Commenter triggers nothing. This is the most common cause of “it works for me but not for them.” If you cannot give everyone edit rights, an installable trigger sidesteps the problem by running under your account.
2. The script was never authorized by that user
The fix: have each editor run the script once to authorize it, or switch to an owner-run installable trigger.
Apps Script asks each user to approve the permissions a script needs. When a shared editor never runs it manually, or dismisses the authorization prompt, the script stays unauthorized for them and fails quietly. An installable trigger you own carries your authorization for everyone.
3. A simple trigger where you need an installable one
The fix: create an installable onEdit trigger instead of a simple one.
Simple triggers run with limited authorization and cannot use services that require permission, such as sending email, calling an external API, or accessing another file. Google’s triggers guide spells out the difference. An installable trigger runs as the owner with full authorization, which fixes most shared-sheet failures.
4. A protected range or sheet
The fix: add the account that runs the script to the protected range’s editor list.
A protected range or sheet blocks edits from anyone not on its editor list, and a script writing as that user is blocked too. If your automation writes to a protected area, either add the running account as an approved editor of that protection, or run the write through an installable trigger owned by someone who is.
5. “Editors can’t change permissions or add new people”
The fix: turn that restriction off, or run any sharing action as the owner.
This toggle in the share dialog stops editors from sharing the file or adding collaborators, which breaks scripts that grant access or add editors programmatically. If your script shares copies or adds people, either loosen this setting or make sure the code runs under the owner’s account.
6. Link sharing set to Restricted
The fix: match the file’s link access to how your web app or script is meant to be reached.
A script others open as a web app, or one that reads a file by link, fails when the file is Restricted to specific people. Decide who should reach it, then set link sharing to “Anyone with the link” or a specific domain to match, rather than leaving a mismatch between the file and the deployment.
7. The web app’s “Execute as” is wrong
The fix: for shared templates, deploy the web app to execute as you, with access set to match your users.
A web app can run as the accessing user or as you. If it executes as the user, each person needs their own permissions and authorization, which is where shared templates break. Deploying “Execute as me” with the right “Who has access” is usually what people actually want for a tool others just use.
8. A copied template that lost its triggers
The fix: recreate the triggers in the copy, or add an onOpen that installs them.
When someone makes a copy of your template, the bound script comes along but the installable triggers do not, because triggers belong to the original owner. The copy then looks identical yet does nothing on edit. Add a setup function or an onOpen prompt that installs the triggers for the new owner on first use.
9. A Workspace admin restricted Apps Script
The fix: check with your admin, since the script or add-on may need to be allowed for the org.
Google Workspace admins can turn off Apps Script, block unverified apps, or limit who can run scripts across the whole organization. If a script fails for everyone in one company but works on a personal account, an admin policy is the likely cause, and only the admin can lift it.
10. An “unverified app” warning
The fix: keep the script inside your own organization, or complete Google’s verification for outside users.
A script that needs sensitive scopes shows a “Google hasn’t verified this app” screen, and outside users are often blocked or scared off. For an internal tool this is fine once your own users click through, but sharing it beyond your domain usually means going through Google’s app verification first.
11. External sharing blocked by domain policy
The fix: keep the workflow inside your domain, or ask the admin to allow the specific external target.
Many organizations block sharing files outside the company, and that policy also stops a script from sharing a file externally or, in stricter setups, from calling outside URLs. If your automation reaches beyond the domain, confirm the policy allows it before assuming the code is wrong.
12. A Shared Drive role that is too low
The fix: give the running account at least Content manager where it needs to edit structure or sharing.
On a Shared Drive, roles matter more than on My Drive. A Contributor can edit content but not manage sharing, and a Viewer cannot edit at all, and a script inherits those limits. If your automation moves, shares, or restructures files on a Shared Drive, the account running it needs a high enough role.
13. “Download, print, and copy” turned off for viewers
The fix: re-enable that option, or run the export or copy step as the owner.
Disabling the option for viewers and commenters to download, print, and copy also blocks scripts that export a sheet to PDF or duplicate it for those users. If an export script fails only for viewers, this quiet checkbox in the share settings is often the reason.
How We Chose These
We built this around the single most common complaint, a script that works for the owner and fails for everyone else, and traced it back to the settings actually responsible. We prioritized the sharing and permission toggles that fail silently, because those are the ones people waste hours debugging in code that is fine. We leaned toward fixes you can apply without rewriting anything, especially moving logic to installable triggers, since that resolves a large share of shared-sheet failures on its own.
The Bottom Line
If a Google Sheets script runs for you but not for the people you share it with, start with three checks: are they editors, is the trigger installable rather than simple, and did the triggers survive a template copy. Those three cover most cases. From there, work down to protected ranges, web app deployment settings, and Workspace admin policies. When automations break after a permission change, the same pattern shows up elsewhere too, as our note on the Zapier permission-changed error shows, and template quirks like the Sheets bracket template paste issue are worth knowing when you share copies.
Frequently Asked Questions
Why does my Google Sheets script work for me but not for shared users?
Usually because the script relies on a simple trigger and the other users are viewers, or they never authorized it. Simple triggers like onEdit only run for people who can edit and have approved the script’s permissions. The reliable fix is an installable trigger, which runs as you with your authorization, so shared users do not need edit rights or their own approval.
Why did my Apps Script stop working after someone copied the template?
Because installable triggers do not copy with the file. The bound script code comes along, but the triggers that fire it belong to the original owner, so the copy does nothing on edit. Add a setup function or an onOpen prompt that installs the triggers for whoever copies the template.
Can a viewer run an Apps Script in Google Sheets?
Not through a simple trigger or a manual run, since those require edit access. A viewer can interact with a web app or a script deployed to run as the owner, because that executes under the owner’s permissions rather than theirs. If viewers need to trigger automation, build it as an owner-run installable trigger or web app.
How do protected ranges affect my script?
A protected range or sheet blocks edits from anyone not on its editor list, and a script writing as one of those users is blocked the same way. Add the account that runs the script to the protected range’s editors, or route the write through an installable trigger owned by an approved editor, so the automation has permission to change the cells.
Why is my script blocked by a “Google hasn’t verified this app” message?
That warning appears when a script requests sensitive permissions and has not gone through Google’s verification. Inside your own organization, your users can usually click through it. To share the script with people outside your domain without the warning or a block, you generally need to complete Google’s app verification process first.
Closing Thoughts
Almost every “my Sheet script is broken” story is really a permission story, and the code was fine all along. When you build something for other people to use, decide up front who runs it, lean on installable triggers so it runs as you, and check the sharing settings before you blame the script. For more practical software and automation guidance, browse Wayodd’s Computing section.