Quick answer: Google Apps Script data regions are now generally available for eligible Google Workspace editions. If an administrator assigns a U.S. or Europe data-region policy, covered Apps Script project data is stored in that region and eligible script execution is processed there automatically. There is no end-user switch. Administrators should review the advanced setting before changing it because non-regionalized classes and advanced services can fail when cross-region processing is disabled. [1][2]
Do this first: inventory scripts and triggers, identify the non-regionalized services listed below, test with a small organizational unit, and only then expand the policy. Do not treat “stored in-region” as proof that every external API, log, cache, or connected system is regionalized. Google’s coverage documentation explicitly limits the promise to listed covered data and services. [4]
What changed on September 16, 2026?
Google announced general availability on September 16, 2026. Under an assigned data-region policy, Apps Script project files, code definitions, manifests, trigger metadata, Properties Service data and Cache Service data are stored in the selected region. Script executions, container-bound automations and associated runtime operations are processed in that region for editions that include in-region processing. Rapid Release and Scheduled Release domains are listed as available now. [1]
Who gets Apps Script data-region support?
| Workspace edition | Apps Script coverage stated by Google |
|---|---|
| Enterprise Plus | In-region storage and processing |
| Frontline Plus | In-region storage and processing |
| Education Standard | In-region storage only |
| Education Plus | In-region storage only |
This is the Apps Script availability list in the launch notice, not a claim that every Workspace edition receives the same controls. Advanced-setting availability also depends on the organization’s edition or Data Regions add-on. Confirm the actual controls shown in your Admin console before planning a compliance change. [1][2]
Five-minute admin path
- Open the Google Admin console.
- Go to Menu → Data → Compliance → Data regions and confirm the geographic policy assigned to the intended organizational unit or group.
- Confirm that Process data in the region selected for data at rest is enabled if your edition supports processing controls.
- Open Data regions → Advanced settings, select the relevant service and organizational unit or group.
- Review the choice to enable or disable features that may process data across multiple regions. The cross-region option is enabled by default.
- Apply the stricter option to a test organizational unit first, then run every important automation before a broad rollout.
Google says Apps Script follows the administrator-assigned policy automatically; users do not configure it themselves. The advanced setting is visible only when the required Enterprise Data Regions capability is available. [1][2]
Pre-change Apps Script audit checklist
- Owners and scope: list standalone, Sheets-bound, Docs-bound and Forms-bound projects owned by users in the target organizational unit.
- Triggers: record time-driven, form-submit, spreadsheet and calendar triggers, including the account that executes each trigger.
- Services: search source code for the classes and advanced services in the next section.
- External paths: record UrlFetch destinations, JDBC databases, webhooks, APIs and connected cloud projects. Apps Script regionalization does not make an external destination regional.
- Logs: identify scripts that depend on Cloud Logging or execution-history logs, especially projects created before 2018.
- Test cases: save a known input and expected output for each business-critical automation.
- Rollback owner: name the administrator who can restore the previous advanced setting if production scripts fail.
Services that can fail under strict regional settings
Google’s current advanced-settings documentation identifies these non-regionalized Apps Script classes: Charts, FormApp, GroupsApp, Jdbc and Maps. It also lists these non-regionalized advanced services: Admin Directory, Admin Reports, AdSense, Analytics, Analytics Admin, Analytics Data, BigQuery, Chat, Classroom, Shopping Content, Merchant API, DoubleClick Campaigns, Tag Manager, Tasks, YouTube, YouTube Analytics and YouTube Content ID. When the relevant strict setting is active, calls can fail instead of silently running outside the region. [2]
Treat that list as a living document. Re-check Google’s page before each policy change because services can become regionalized or the affected list can change.
Important enforcement-date discrepancy
Two current Google pages do not state the same enforcement timing. The September 16 launch post says non-regionalized Apps Script services will be disabled starting in September 2026 for organizations that turn on the Drive and Docs disablement toggle. The advanced-settings help page says enforcement of non-regionalized feature disablement started May 15, 2026. Because both pages are official and the dates conflict, do not build a rollout around either date alone: assume enforcement can already apply, inspect your tenant and test the scripts. [1][2]
How to test without breaking production
- Create or choose a small test organizational unit with representative accounts and the same Workspace edition as production.
- Copy non-sensitive test versions of critical scripts; do not duplicate production secrets into a test project.
- Run manual functions and every installable trigger path.
- Exercise each connected service, including BigQuery, Maps, Forms, JDBC, YouTube or Admin SDK calls where used.
- Open Executions in Apps Script and record failures, duration changes and missing logs.
- Check downstream systems to verify that the intended action actually completed; a trigger marked as started is not proof of business success.
- Expand by organizational unit in stages and keep a tested rollback path.
How to fix the “Class / Apiary service is disabled” error
Google documents the error pattern <Class> / Apiary.<Service Name> is disabled. Please contact your administrator to enable it for scripts that invoke a non-regionalized class or advanced service while strict regional controls are active. [3]
- Note the exact class or service named in the error and the failing execution’s user.
- Confirm the user’s organizational unit or group and its inherited data-region policy.
- Compare the service with Google’s current non-regionalized list.
- Decide whether to replace the dependency, move that workflow to an approved regional architecture, or—only after compliance review—allow the cross-region feature for the relevant scope.
- Re-run the same test input and verify the downstream result.
For older scripts, execution logs may also be unavailable when regionalization controls apply. Google’s troubleshooting guide says some pre-2018 projects can show a Cloud Logging suppression notice; use a standard, user-managed Google Cloud project where appropriate and verify the organization’s logging requirements separately. [2][3]
What data regions do not automatically cover
Do not assume the setting regionalizes every piece of an automation. Google says data types not specifically listed—such as some logs or cached content—are not covered by a data-region policy. External API providers, webhook receivers, databases and custom cloud projects have their own storage and processing locations. Document the full data path before using this feature as compliance evidence. [4]
Frequently asked questions
Do users need to change their Apps Script settings?
No. Google says project creation and executions automatically follow the data-region policy assigned by the administrator. There is no end-user setting. [1]
Does Apps Script support both U.S. and Europe regions?
Google Workspace data regions allow covered data to be assigned to the United States or Europe. Actual storage-only versus storage-and-processing coverage depends on the Workspace edition. [4][1]
Will existing scripts keep working?
Many will, but a script that calls a listed non-regionalized class or advanced service can fail when the relevant strict advanced setting is enabled. Test business-critical scripts before changing a production organizational unit. [2][3]
Does this guarantee that an automation is compliant?
No. The control helps keep specified covered data and processing in a selected region, but compliance also depends on your edition, configuration, external systems, access controls, retention, contracts and applicable requirements. Use the setting as one technical control, not as a blanket compliance certificate.