Hey everyone,

I wanted to open a discussion on handling one of the most notorious and frustrating limitations in Google Apps Script add-on development: the multiple accounts Authuser=0 trap.

The Context: My team recently launched a Workspace management add-on. Shortly after launch, we onboarded an enterprise client who left a great review but immediately reported a frustrating "nitpick": he's logged into multiple Google Workspace accounts, while he's accessing the add-on with his second logged account, the sidebar of our add-on was selecting the default account of their browser rather than the account actually linked to the active spreadsheet.

After consulting with my lead dev, we realised we were dealing with a platform-level infrastructure issue, and not a bug in our code.

The Trap: As most of you know, when a user is juggling multiple Google accounts in one Chrome window (e.g., u/0/, u/1/), Google Apps Script's HtmlService often gets completely confused by the session cookies. If they open the sheet with a secondary account, the underlying iframe still forces the add-on to authenticate using the Default account (authuser=0).

The result is massive user confusion, as the sidebar displays data or permissions for the completely wrong account.

No Workaround Found: We searched high and low but couldn't find a native programmatic patch to force the iframe to respect the active document's user context. So we advised the client to perform their admin operations inside a dedicated Chrome Profile or an Incognito window.

My Questions for the Community: Since we want to provide the smoothest UX possible, I’m curious how other devs here are tackling this:

1. The "Holy Grail" Fix: Has anyone found a reliable native workaround, undocumented parameter, or JS hack to force HtmlService to respect the active authuser index?
2. User Experience (UX): Do you preemptively warn users about this in your UI/onboarding flow, or do you just document it in your FAQs and wait for the support tickets to roll in?
3. Google's Roadmap: Has anyone who talks to Googlers heard any whispers on whether this is ever getting patched at the infrastructure level?

Would love to hear your thoughts, workarounds, and war stories regarding this bug!

Hey everyone,

I wanted to open a discussion on handling one of the most notorious bottlenecks in Apps Script development: the 6-minute execution wall (and the dreaded “Resource Exhausted” errors).

The Context:

My team recently built and launched a sheet-based Workspace management add-on called AdminSheet Pro. Our biggest technical hurdle wasn’t the Directory API logic itself, but dealing with massive enterprise and Higher-Ed domains. When you are trying to bulk update 10,000+ users or migrate massive nested groups, hitting that 6-minute wall is almost guaranteed.

We noticed that a lot of other sheet-based tools in the ecosystem just slap a warning label on their UI saying something like:  “Organizations with 10k+ users may experience timeouts due to Apps Script runtime limits.” We felt that defeated the purpose of building a “bulk” tool, so we decided to try and engineer a native workaround.

Our Approach: “Intelligent Pacing”

Instead of trying to brute-force the API or migrating the entire execution engine off Apps Script to GCP, we engineered a state-management architecture we call Intelligent Pacing.

Essentially:

1. We track row-level execution state continuously.
2. We anticipate the execution wall around the 5.5-minute mark.
3. We gracefully pause the script, save the state, and use triggers to spin up the next batch seamlessly in the background.

We made a conscious design choice to prioritise guaranteed completion over raw speed. It might take a little longer to run safely, but it doesn’t crash halfway through. We also had to build real-time, row-by-row visual feedback in the Sheet to prevent “terminal anxiety”—so admins wouldn’t panic and kill the script while it was processing in the background.

My Questions for the Community:

Since we are always looking to optimise, I’m curious how other devs here are tackling this:

1. Architecture: Are you using a similar trigger-based batching system to stay within Apps Script, or have you offloaded the heavy lifting entirely to Cloud Run/Cloud Functions?
2. UX: How do you handle user UX when background tasks take 15+ minutes? How do you keep the user informed without exceeding quota limits on UI updates?
3. Batching: Have you found a “sweet spot” for API batching sizes to maximise throughput before you hit that 6-minute mark?

Would love to hear your thoughts and strategies!