Let’s break down the most likely reasons why this is happening, along with practical fixes for each scenario:

1. Web App Deployment with Incorrect Execution Permissions #

This is by far the most common culprit. If you’ve deployed your script as a Web App and selected the wrong execution identity, every user will run the script under your (the developer’s) account—meaning they’ll all access your UserProperties instead of their own.

• How to check: Go to your script project → Deploy → Manage deployments. Look at the "Execute as" setting for your active deployment.
• Fix: Change the "Execute as" option to "User accessing the web app". This ensures each user runs the script under their own Google account, so their UserProperties are fully isolated.
• Important: After updating this setting, you’ll need to deploy a new version of the Web App (click Deploy → New deployment) for the change to take effect.

2. Accidental Use of Shared Property Stores #

Double-check that you’re consistently using PropertiesService.getUserProperties() everywhere in your code. It’s easy to mix up property types by mistake:

• PropertiesService.getScriptProperties(): Shared across all users of the script
• PropertiesService.getDocumentProperties(): Shared across all users of the parent Google Sheet/Document
• PropertiesService.getUserProperties(): Unique to each individual user

If any part of your code (like a save or retrieve function) uses one of the shared property stores instead of getUserProperties(), all users will end up sharing the same settings pool.

Fix: Do a full search of your script project for getScriptProperties or getDocumentProperties and replace them with getUserProperties() where appropriate.

3. Testing with Cached Developer Sessions #

If you tested the script yourself using your developer account, then had other users test without them logging out of your account or using incognito mode, you might be seeing cached authorization or execution context.

• Fix:
  • Ask users to test in an incognito window (to bypass cached sessions)
  • Ensure each user is logged into their own Google account when interacting with the script
  • For container-bound scripts (like in Google Sheets), have users refresh the sheet and re-run the function to confirm they’re executing it under their own identity

4. Stale Script Deployment or Cached Code #

If you’ve updated your script to use getUserProperties() but haven’t re-deployed it (for Web Apps) or users are still loading an old version from cache, they’ll keep running the code that uses shared properties.

• Fix:
  • For Web Apps: Deploy a new version (as mentioned in point 1) and share the fresh deployment URL with users
  • For container-bound scripts: Ask users to go to Extensions → Apps Script, click the refresh button in the script editor to load the latest code, then refresh the parent sheet

内容的提问来源于stack exchange，提问作者Egor