Who can edit a flow

Permissions decide whether you may work with flows at all. Which flows you may change is a separate question, answered per flow.

Reading is not per flow. Anyone holding Flow__Read sees every flow in the workspace — its versions, its files, its runs — whether they wrote it or not. Opening a colleague's flow in the editor is expected, and it opens read-only.

Changing one is limited to:

• its author;
• anyone it has been shared with;
• a workspace owner, who can change everything;
• anyone whose role carries Flow Access (FlowAccess__Write) — the author's standing on every flow in the workspace, without the rest of ownership. See Roles and permissions.

Sharing one#

From the flow's own page, share it with a member of the workspace. There is one level, because there is nothing else left to grant: a share means this member may edit this flow.

Only the author, a workspace owner, or a holder of Flow Access can change who a flow is shared with. Being shared a flow lets you change the code; it does not let you hand it on to somebody else.

Editing#

Writing to a flow needs both of:

1. Flow__Write in the workspace, and
2. being the author, a workspace owner, having the flow shared with you, or holding FlowAccess__Write.

Neither substitutes for the other: a share does not grant Flow__Write, and Flow__Write does not let you edit a flow that is not yours. FlowAccess__Write is the exception that answers both at once — it implies Flow__Write, and it satisfies the second line for every flow.

The flow page says which one you have — the button reads Edit code or View code, and the editor shows a Read-only badge when it cannot be saved.

What inherits the verdict#

Deployments, executions, webhooks and schedules do not compute their own answer — they inherit the flow's. Since reading a flow is workspace-wide, so is reading its deployments and their runs: an on-call operator needs Deployment__Read and nothing else to see what a flow is doing.

Editing follows the flow too. Publishing a version, pointing a deployment at one, and binding a trigger all change what runs in production, so they stay with the author, the owner and the members the flow is shared with.

One exception, in the other direction: a webhook or schedule that drives no deployment has no flow to inherit from, so only the member who created it — or a workspace owner — can change it. Everyone can see it. FlowAccess__Write does not reach it either: there is no flow whose access it would be standing in for.

System flows#

Some flows belong to the platform rather than to you. They can be read where they are visible and cannot be modified by anyone, including a workspace owner or a Flow Access holder. An attempt to edit one is refused rather than silently ignored.

Next#

• Roles and permissions — the other half of the answer.