Prepare for upcoming authorization changes

Application Integration is updating how it authorizes integrations. These changes take effect for new integrations on October 15, 2026, and for existing integrations at a later date. Most integrations continue to run without changes, but some require a configuration update to keep running. You can make the changes described on this page now because they use configurations you already control.

Upcoming authorization changes

Application Integration is updating how it handles identities for integration runs. Every run must now have an explicit identity, acting as one of the following:

• The user who triggered the run. The called systems apply that user's access permissions.
• A run-as service account. You control, scope, and audit this account like any other service account in your Google Cloud project.

Because of this update:

• To publish or test an integration that has a run-as service account, you must have permission to act as that account. Running the integration, approving its suspended runs, and calling it from another integration will require the same permission as the rollout proceeds.
• Starting October 15, 2026, you can't publish or test a new integration with a scheduled or event trigger without a run-as service account. Runs that reach a task without an identity, and asynchronous runs of any integration without a run-as service account, are planned to fail in a later release.

When these updates take effect

Integration	When the updates apply
Created on or after October 15, 2026	From the first version you create. Every version you publish afterward retains the new behavior.
Created before October 15, 2026	These integrations keep their current behavior until a later date, which Application Integration announces separately.

Note: Editing an integration doesn't change its stage, and a sub-integration runs in the stage of the integration it belongs to. Two things don't depend on the stage:

• Service Account User checks apply to every integration, whatever its creation date.
• Starting October 15, 2026, every test uses the new behavior, including tests that you start from the Google Cloud console and tests of integrations created before that date.

What to do

Make these changes now, whichever stage your integrations are in. They take effect as soon as you make them.

1. Find integrations that need a run-as service account: integrations that run asynchronously, on a schedule, or from an event, and don't have one.
2. Grant Service Account User on each run-as service account and each authentication profile's service account, to everyone who runs, tests, publishes, or approves the integration, and to the service accounts your triggers and automation use.
3. Set a run-as service account on each integration you found, and publish it.

Warning: Complete step 2 before step 3. Publishing an integration with a run-as service account requires Service Account User on that account, so if you set the service account first, the publish can be rejected.

If something fails after the change, see Troubleshoot authorization errors.