Service accounts (workflow execution identities)
Create machine identities with their own clearance, bind them to workflows as execution identities, and revoke them — from the organization Members page.
A service account is a machine identity (an OAuth client_credentials client) that belongs to your organization. By default it is a standard service account — you choose its scopes and copy its client secret to call the platform API.
This page covers the optional execution-clearance mode. When you assign a service account an execution clearance at creation, it becomes a workflow execution identity instead: it carries its own clearance, the platform keeps its secret host-confined (there is no secret to copy — the host mints short-lived tokens itself), and it can be bound to a workflow. When a bound workflow runs, storage and credential access is performed as the service account — not as the person who authored or triggered the workflow. Access decisions, audit rows, and clearance gates all attribute to the machine identity.
Execution clearance is opt-in. Leave it as None — standard service account to get the ordinary external-M2M account above. Assigning a clearance switches the account to a host-confined execution identity (no secret is shown). And a bound execution identity only changes a workflow's behavior once you bind it — unbound workflows keep running on behalf of their author.
Where they live
Service accounts are managed on the organization Members page (Settings → Organization → Members), grouped separately from human users so it is always clear who is a person and what is a machine identity:
- Users — your human organization members (invite, roles, removal).
- Service Accounts — machine identities (name, client ID, clearance, status, revoke).
Create a service account
On Settings → Organization → Members, open the Service accounts tab and select Add Service Account.
Give it a name (e.g. production-runner), then set Execution clearance to a level from your organization's active classification scheme (instead of the default None). You can only assign a clearance at or below your own.
Select Create Service Account. The new Client ID is shown with a copy action — use it to bind the account to a workflow.
When you assign a clearance there is no secret to copy or store. The platform keeps the client secret encrypted server-side and mints short-lived tokens itself whenever a bound workflow runs — neither you nor the workflow runtime ever handles the credential. (Leaving clearance as None instead creates a standard service account whose secret you copy once.)
Creating service accounts requires the organization member: create permission (org admins have it); revoking requires member: delete.
Bind it to a workflow
Set the workflow's execution identity to the service account's client ID. Binding is accredited: you can only bind an identity whose clearance is at or below your own — an author can never escalate a workflow above themselves, and an author without a clearance cannot bind at all.
Once bound:
- The workflow's storage and credential access runs as the service account, gated by the account's clearance (no read-up).
- Audit rows attribute actions to the service account, with the run that performed them.
- Connections that require a clearance above the account's are invisible to the workflow.
Revoke
Revoking a service account (the ✕ action on its row) disables it immediately. Workflows still bound to it fail closed on their next run — they do not silently fall back to running as their author. Re-bind the workflow to a new identity, or unbind it to restore author-identity execution.