Flow Permissions
A Flow is governed by user roles, the platform-level roles that apply across the deployment. Viewing Flows and executions is open to every role. Changing a Flow is not decided by the role alone: to create, edit, publish, activate, execute, abort, or delete a Flow, a Manager must also hold the Editor team permission on every datastore the Flow references. Admins bypass that check.
User Roles
| Action | Member | Manager | Admin |
|---|---|---|---|
| View Flows and their configuration | |||
| View executions and their details | |||
| Create and publish a Flow | |||
| Edit and publish changes to a Flow | |||
| Activate or deactivate a Flow | |||
| Execute a Flow | |||
| Abort or delete an execution | |||
| Delete a Flow |
UI Behavior Without Permission
| Scenario | What the User Sees |
|---|---|
| A user cannot manage a Flow | The row's options menu is hidden on the Flows list, and the canvas offers no editing controls. |
| A user cannot manage an execution | The row's Abort and Delete buttons are hidden, and bulk selection explains that the user doesn't have permission to manage the execution. |
| A user without the Manager role opens the Flows page | The Add Flow button is not shown. |
See Also
-
How It Works
The canvas, Flow settings, chaining rules, and the publish lifecycle behind every edit.
-
Triggers
The six trigger types, schedule configuration, and the filter conditions each type supports.
-
Actions
The five action categories, the chaining rules between them, and where each is documented.
-
Executions
The Definitions and Executions tabs, execution states, and the read-only execution graph.
-
Examples
Real scenarios showing how a trigger and a chain of actions combine into a working automation.
-
Best Practices
Guidelines for building Flows that stay quiet when healthy and loud when something breaks.