A role is a named set of permissions, assigned to members of a workspace. The vocabulary is deliberately small: thirteen domains, two verbs.
Every permission is Resource__Read or Resource__Write. There is no "manage" and no "execute".
__Read — list, get, and every derived read: stats, events, payloads, logs.__Write — create, update, delete, and any state change.__Write implies __Read for the same domain, so a role never needs to list both.
Two domains carry only one of the two verbs, because the other would have nothing to govern: Activity has no write half (nothing may edit an audit trail) and Flow Access has no read half (reading flows is already workspace-wide).
| Domain | Covers |
|---|---|
| Flow | Flows, versions, draft files, static assets, shares, libraries, publishing, flow folders |
| Flow Access | Editing, sharing and deleting any flow in the workspace — not just your own. Write only |
| Deployment | Deployments, their input config, their granted permissions, deployment folders |
| Trigger | Webhooks, schedules, event sources, trigger bindings, recorded events and their payloads |
| Execution | Executions, logs, results, payloads — and every route that starts, replays, cancels, resumes, releases or discards a run |
| DataStore | Stores, columns, records, lookups |
| Connection | Connections, the OAuth2 flow, reconnect |
| Service | Workspace service definitions (platform services are read-only for everyone) |
| WorkspaceVariable | Workspace environment variables |
| Member | Members, invitations, role and ownership changes |
| Role | Roles and their permission sets |
| Workspace | Workspace settings and the activity dashboard |
| Activity | The audit trail — read-only, no write half |
A permission covers a domain, not a table. Flow__Read covers the flow, its versions, its
draft files, its shares and its libraries, because those are all "the flow" to the person ticking
the box.
A request has to clear all three. None substitutes for another:
| Check | Question |
|---|---|
| Permission | May this caller do this kind of thing at all? |
| Tenancy | Is this row in a workspace they belong to? |
| Object access | Is this particular flow one they may see or edit? |
So Flow__Read decides whether you may read flows — all of them, workspace-wide — and
Flow__Write plus a share decides which ones you may change. Granting the permission does not
widen what a share allows, and a share does not substitute for the permission.
Deployments, executions, webhooks and schedules inherit the flow's verdict rather than computing their own — for reading and for editing alike.
FlowAccess__Write is the grant for a lead developer or an on-call engineer: it gives the flow
author's standing on every flow in the workspace, so they can edit, publish, share and delete
one they never wrote and were never shared.
It is the only permission that answers "which flows" rather than "what kind of thing", and it exists because the alternatives were both bad: making that person a workspace owner also hands them billing, the member list and the role editor, while sharing every flow with them is one write per flow that goes stale as soon as somebody writes another.
Ticking it implies Flow__Write, so the box is enough on its own. What it does not widen:
Flow__Write,
not of Deployment__Write — editing the code and changing what production runs stay apart.| Role | Permissions | What it cannot do |
|---|---|---|
| Operator / on-call | Deployment__Read, Execution__Write, Trigger__Read | Edit source, publish, or repoint an ingress URL |
| Developer, no production | Flow__Write, Execution__Read | Start a run, release held deliveries, change a deployment |
| Lead developer | FlowAccess__Write, Execution__Read | Change a deployment, touch billing, invite members, or edit roles |
| Integrator | Trigger__Write, Deployment__Read, Connection__Write | Read run payloads, edit flow source |
| Auditor | Activity__Read, Execution__Read, Member__Read | Write anything at all |
| Support | Execution__Read, Flow__Read, DataStore__Read | See connections, variables or the member list |
Owners. A workspace owner bypasses every check; assigning them a role changes nothing.
The navigation. The app hides sections whose list route the caller cannot read, so a narrow role sees a shorter sidebar rather than a menu of error pages. That is presentation — the gate is enforced on the API regardless.
A deployment runs as its own machine identity with its own granted permissions, set on the deployment rather than inherited from whoever deployed it. A flow can be allowed to read executions while being unable to create deployments.
This is why repointing a deployment at a different version is permission-checked: new code will act with that identity's authority, so whoever repoints it must hold everything the identity holds. See Versions and rollout.