Find integrations that need a run-as service account

This page is part of Prepare for upcoming authorization changes. It helps you find the integrations that need a run-as service account before the changes take effect.

Determine whether an integration needs one

You only need a run-as service account when nobody's credentials are available for the whole run. That happens in two situations, and only two:

How the integration runs	Are someone's credentials available?	Needs a run-as service account?
Synchronously — someone starts it and waits for the result	Yes, for the whole run	No
Asynchronously — it's queued and finishes later	Only at the moment it's triggered	Yes
Unattended — a schedule or an event starts it	No, there's never a person	Yes

Note: Asynchronous runs count even though a person triggered them: queued work doesn't carry that person's credentials, so by the time it runs there's nobody left to authorize it. An integration that only ever runs synchronously already has an identity and needs no change, unless it calls another integration asynchronously. That other integration needs its own run-as service account.

Identify affected integrations

First, does it ever run without a person? It does if any of these are true:

• It has any trigger other than an API or Private trigger, for example a Schedule, Cloud Scheduler, Cloud Pub/Sub, Salesforce, Integration Connectors event, or Eventarc trigger.
• Something schedules it through the API with scheduleIntegrations.
• Another integration calls it as an asynchronous sub-integration, using the Call Integration task. The sub-integration needs its own run-as service account even if the calling integration has one.
• It uses the Suspend or Approval task, where a run can sit waiting and then expire on its own.

Second, is its run-as service account empty? To list every published version in a region alongside its run-as service account, run the following command:

curl -s -G -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  --data-urlencode "filter=state=ACTIVE" \
  --data-urlencode "pageSize=1000" \
  "https://REGION-integrations.googleapis.com/v1/projects/PROJECT_ID/locations/REGION/integrations/-/versions" \
| jq -r '.integrationVersions[]
         | [ .name, (.runAsServiceAccount // "NONE") ]
         | @tsv'

Replace the following:

• REGION: the region of your integration. For the list of supported regions, see Locations.
• PROJECT_ID: the ID of your Google Cloud project

• A row showing NONE needs action only if the first half applies to it too.
• To check a single integration instead, open it in the integration editor and click (Integration settings) in the editor toolbar. The Service account field shows the run-as service account, and is empty if the integration doesn't have one.

Caution: Keep filter=state=ACTIVE on the request rather than filtering the output afterwards. The - wildcard returns one version per integration — the most recently modified one — so if you fetch everything and filter later, any integration whose newest version is an unpublished draft drops out of the results even when it has a published version that is still running. If the response contains a nextPageToken, repeat the request with pageToken=TOKEN until the token stops coming back.

Warning: Don't wait for a warning in the Google Cloud console. Warnings depend partly on observed runs, so an integration on an infrequent schedule, or one nobody has triggered lately, can need action without ever showing one. Check your scheduled and event-driven integrations with the steps on this page instead.

What's next

• Grant Service Account User on the run-as service accounts you already use.
• Set a run-as service account on each integration you found.