Who a flow runs as
A flow acts with the permissions of the person who last changed it. Learn what that means for access, edits and leavers.
A flow does not act as a robot with special rights. Every block runs with the permissions of one person: the last person who changed what the flow does. A flow can never do something that person could not do themselves.
Who that person is
- When you create a flow, it runs as you.
- When someone saves a change to the blocks, the connections, the trigger or the flow context, the flow now runs as them.
- These changes do not change who the flow runs as: switching it On or Off, renaming it, editing the description, and moving blocks around the canvas.
So a person with permission to edit flows cannot make a flow run with somebody else's access to a graph they did not write. Whoever changes the logic takes responsibility for it.
What this means in practice
- Records. Update record and Create record follow that person's record permissions, including fields they are not allowed to see or change.
- Reading the trigger. A Record event flow reads the record's values as that person. A Calendar event flow reads the event as that person, and skips events they cannot read.
- Functions. A Run function block needs the person to be allowed to run functions (Can run on Custom code). The function also has its own rule about whose access it uses. See Limits and permissions.
- Calendars. In a Create event block the Calendar menu lists the calendars the person can see.
- Pressing Run. When someone presses Run, the flow still runs as its author, not as the person who pressed the button. That is why Can run only lets someone start flows; it does not give them the flow's powers.
If the person leaves
If the person the flow runs as is no longer a member of the workspace, the flow is skipped. Open it, make a small change to the logic and save so it runs as you. Check their replacement has the access the flow needs.
Permission levels
On the Roles page the app is called Automations:
| Level | Lets someone |
|---|---|
| No access | Not open Flows. |
| Can view | See flows and their run history. |
| Can run | Also trigger a flow by hand. |
| Full control | Build and delete flows. A flow acts with its author's permissions, so this is a trusted job. |
The workspace owner implicitly holds every permission.
Tips
- For a flow that must keep working, have a stable role-holder (for example the owner) make the last change.
- If a flow starts failing with permission errors after someone's role changed, the person it runs as lost some access. Compare it with their roles in Team and permissions.