Workflow Access Control — Overview
Four roles, tenant isolation, and API-level enforcement. This guide covers who can view, edit, and execute workflows in Flow Studio and how that access is stored and checked.
The Four Access Roles
Owner
Full control — design, execute, share, delete. The creator of a workflow is always its initial Owner.
Editor
Can design and execute. Cannot share (grant access to others) or delete the workflow.
Viewer
Read-only access to the canvas and execution history. Cannot change the definition or trigger execution.
Executor
Can trigger execution only. Cannot see the canvas design or edit anything.
Where Access Is Checked
Access is enforced at the API gateway layer — before any engine code runs. Every controller action that touches a workflow passes through the ProcessAccessGuard middleware, which calls IProcessAccessChecker.CheckAsync. If the check fails, the request is rejected with 403 Forbidden before the engine sees it.
Tenant Isolation
Every workflow (Process) belongs to exactly one tenant. A workflow is never visible outside its owning tenant, even if actors from other tenants exist in the system. There is no cross-tenant sharing. The only exceptions are:
- Tenant Admin accounts have read access to all workflows in their tenant for audit purposes.
- Platform Admin accounts (rare, Anthropic/BizFirst staff) can view across tenants for support.
Role Capability Matrix
| Action | Owner | Editor | Viewer | Executor |
|---|---|---|---|---|
| View canvas | Yes | Yes | Yes | No |
| Edit nodes/edges | Yes | Yes | No | No |
| Execute workflow | Yes | Yes | No | Yes |
| View execution history | Yes | Yes | Yes | Yes |
| Share (grant/revoke access) | Yes | No | No | No |
| Delete workflow | Yes | No | No | No |
| Export / import | Yes | Yes | No | No |