Run As — Workflow Identity
Configure which identity a workflow runs under, optionally delegating execution to a service account with linked OAuth credentials.
By default every workflow runs under the identity of the workflow owner — the user who last saved a promoted version. Run As lets an org admin pin a specific service account as the executing identity instead. Service accounts are non-human machine identities with a declared set of capability scopes and an optional linked OAuth credential per integration product.
Why Run As?
| Use case | What it solves |
|---|---|
| Scheduled automations that call an integration (Gmail, Jira, …) | OAuth tokens attached to a real user expire; a service account credential persists until explicitly revoked |
| Multi-environment deployments | Each environment binds its own SA with the correct scoped access, without sharing user sessions |
| Audit clarity | Execution logs show service_account as the actor type so you can distinguish automated from human-triggered runs |
| Clearance-gated workflows | Service accounts can hold a BLP clearance, so a workflow may operate at a classification level the owner does not personally hold |
Personal vs service account credentials
When an integration block resolves a credential, the access model depends on the account type:
| Account type | Workspace access |
|---|---|
| Personal connected account (owned by the acting user) | Usable in every workspace the owner belongs to — no per-workspace assignment required |
| Service account wallet credential | Must be explicitly linked per workspace by an org admin before it can be used |
If you connect a personal OAuth account (e.g. your own Google Workspace account) and bind a block to Run As identity with the workflow set to Workflow owner, that account is immediately available in any workspace you are a member of.
Service accounts require the extra wallet step described below, giving org admins explicit control over which credentials are active in each workspace.
Service account credentials (the wallet)
Before a service account can substitute for an OAuth user session you must link the OAuth account to it. Only organization admins can manage the wallet.
Connect the OAuth account. Go to Settings → Integrations and connect an OAuth integration (e.g. Google Workspace). This creates a personal OAuth account in the org account list.
Open the service account detail sheet. Go to Settings → Organization → Members, open the Service accounts tab, and click the row for the service account you want to configure.
Link the credential.
In the Credentials Wallet section click Link, select the connected OAuth account from the dropdown, and enter the Product ID (e.g. org:scrydon:google:gmail). You can find the product ID on the integration detail page in the Integrations panel.
The product ID is scoped to the vendor — linking org:scrydon:google:gmail makes that OAuth account available when the workflow needs Gmail access; it does not affect other Google products.
Repeat for each product the workflow needs. One service account may hold credentials for multiple products simultaneously.
Configuring Run As on a workflow
The Settings tab in the workflow's Deployments sheet sets the persistent default identity for all automated and scheduled runs:
- Open the workflow in the editor.
- Click Deploy to open the Deployments sheet.
- Switch to the Settings tab.
- Select a service account from the Run As dropdown or choose Workflow owner (the default).
- Click Save.
The dropdown only shows service accounts that are accredited for this workflow — the service account's BLP clearance rank must be at or above the highest classification in any knowledge base or document the workflow accesses. Unaccredited options are shown but disabled.
Promotion behavior
When you promote a workflow to a new environment:
- First promotion into that environment — Run As is seeded from the source workflow's setting. If you are not accredited for the source service account, the target is created with Workflow owner and a warning is shown in the Promote view.
- Subsequent promotions — the target environment's Run As binding is preserved unchanged. Promotion never overwrites it.
Credential selectors that use the symbolic Run As identity option automatically resolve against the target environment's binding at execution time — no rewriting is required on promote.
Execution attribution
The Runs table in the Monitor tab shows a Run As column for every execution. Possible values:
| Display | Meaning |
|---|---|
service_account badge + name | The workflow ran under that service account |
| User avatar | The workflow ran under the owner's or executor's identity |
| — | Pre-feature execution (no actor metadata) |
Audit logs record the actor type (user or service_account) and the service account ID on every run so compliance teams can identify non-human executions.
Troubleshooting
Workflow fails with RUN_AS_CREDENTIAL_MISSING — the service account's wallet does not contain a credential for the integration product the workflow tried to use. Open the SA detail sheet, add the missing linked credential, and re-run.
If the selector returns RUN_AS_PRODUCT_UNCOVERED the workflow's credential sub-block is bound to "Run As identity" but the service account has no wallet entry for the required product. Link the credential in Settings → Organization → Members → Service accounts before running.
Selector shows "not accredited" — the service account's BLP clearance rank is lower than the knowledge base or document the workflow accesses. Increase the SA's clearance in Settings → Organization → Service accounts or reduce the document classification.
Save returns 403 — your own clearance level is below the service account's BLP rank. You can only bind a service account whose clearance is at or below your own. Contact your org admin to adjust the SA's clearance or your own.
Per-run override returns 403 — your account is not accredited to run this workflow as the chosen service account (same clearance rule as above).
OAuth token expired — an organization admin must reconnect the integration account under Settings → Integrations and re-link it in the SA credentials wallet.