Permissions & Sharing
Account roles, owner vs member inside a team, and per-workflow sharing permissions — three layers stack up to decide who can do what.
What someone can do with a workflow comes from three stacked layers: the account role, their standing inside the team, and that workflow's own sharing settings. Taken one at a time it is simple; mixed together it gets confusing.
Layer 1: account role
| Role | Meaning |
|---|---|
| MEMBER | The default role. Owns what it creates and can gain access to other people's resources through sharing. |
| VIEWER | A read-only account: can inspect the workflows it has access to but cannot create, edit or run them. Suits auditors and limited guests. |
| ADMIN | Platform administrator, visible across accounts. Set by the deployment operator; you cannot request it yourself. |
Layer 2: standing inside the team
A team has exactly two standings: the creator is the owner, everyone else is a member. There are no finer-grained team roles.
| Actions | Owner | Member |
|---|---|---|
| Change the team name and description | ✓ | — |
| Invite new members | ✓ | — |
| Remove Member | ✓ | Can only leave on their own |
| Disband The Team | ✓ | — |
| Manage the subscription and seats | ✓ | — |
| See the team member list | ✓ | ✓ |
| Use team credentials and team workflows | ✓ | ✓ |
Everyone in the same team sees team resources the same way. To separate "who can edit" from "who can only look", use the third layer below — per-workflow sharing permissions.
Layer 3: the workflow's sharing settings
This is where the fine control lives. Each workflow picks a sharing scope, and each of five permissions can be toggled for whoever it is shared with.
- Private — The owner only. This is the default for a new workflow.
- Teams — Every member of a chosen team.
- Designated Members — A named list of accounts.
- Public — Anyone holding the link can view it.
Five permission bits toggle independently: view, edit, execute, re-share and delete. A common combination is team + view + execute — colleagues can run it but cannot change it. A share can also carry an expiry date and lapses automatically.
What each plan allows for collaboration
- Free: no collaboration; workflows are yours alone.
- Pro: you can see what is shared with you, but cannot drive full collaboration management yourself.
- Team and above: full team and sharing permissions.
- The audit-log viewer is opened only on the Enterprise plan; the platform records the events all along regardless.
How common splits map onto this
- Only SRE may edit production workflows — Keep the workflow owned by SRE and share it with the team as view + execute only.
- Compliance looks but does not touch — Give them a VIEWER account, or share with view permission only; where a sign-off is required, use manual_approval to put the person inside the flow instead.
- Keep development and production apart — Create two teams and move a workflow to the production team only after it has proven stable in the development one.
Next
- Teams — How to create a team, invite members, and what to do when the sole owner wants to leave.
- Manual Approval — Put people inside the flow instead of relying on permissions alone to stop things.
- Credentials — The resolution order between personal and team credentials.