Workflow access decides who can see, chat with, change, and delete each workflow, and who can share it with others. It lets you keep a workflow private while you build it, then open it to the people and teams who need it, without giving them control over anything else.How workflow access works#
Two things work together to decide what a person can do with a workflow:1.
Their role on the workflow (Owner, Admin, or Member). The role says which workflows a person can act on. They get it directly from the workflow's access settings, or inherit it from the workflow's project or one of their teams.
2.
Their Permission Sets. Permission Sets are reusable access rules that a Global Admin assigns to people. They say which actions (view, edit, delete, create) a person can take on workflows, and how widely those actions reach.
Workflows can't be made public. Access always comes from a role on the workflow, its project, a team, or a Permission Set.
Workflow roles#
| Role | What it allows | Who gets it |
|---|
| Owner | Full control of the workflow, including editing, deleting, and managing who has access. | The person who created the workflow. It's assigned automatically and can't be transferred or removed. |
| Admin | View and chat with the workflow, change its configuration, delete it, and manage who has access, for each of those actions their Permission Sets allow. | People and teams you choose in the workflow's access settings, or people who are Admins of the workflow's project. |
| Member | View and chat with the workflow, if their Permission Sets allow viewing workflows. Members can't change the workflow, delete it, or see its access settings. | People and teams you choose in the workflow's access settings, or people who are Members of the workflow's project. |
Choose Member for people who only need to use a workflow, and Admin for the people responsible for maintaining it.
Inherited access#
You don't have to add everyone to each workflow. Access also flows from higher levels:| Source | How it works |
|---|
| Project | People with a role on the workflow's project get the same role on every workflow in that project. |
| Team | When a team is given access to a project or a workflow, everyone in the team gets that access. Adding someone to the team, or removing them, updates their workflow access automatically. |
| Organization admins | People with organization-level admin access can manage every workflow in the organization, whether or not they're listed in a workflow's access settings. |
Inherited access still depends on Permission Sets. For example, someone who inherits a workflow from its project can act on it only if one of their Permission Sets covers workflows in the projects they have access to, or a broader scope.When you give a team Member access, its members can only view the workflow, even if their Permission Sets would let them edit or delete it.
Permission Sets for workflows#
Each Permission Set has a workflows section with these settings:| Setting | What it allows |
|---|
| View | View and chat with workflows. |
| Edit | Change a workflow's assistants, connections, and settings, and manage who has access to it. |
| Delete | Delete workflows. |
| Create | Create new workflows. Without it, a person can't create a workflow, even in a project they can view. |
View, Edit, and Delete each have a scope that sets how widely the action reaches:| Scope | Applies the action to |
|---|
| All | Every workflow in the organization. |
| Projects | Workflows in the projects the person can access. |
| Teams | Workflows their teams have access to. |
| Own | Only workflows the person created. |
Workflows are never deployed, so unlike assistants, the workflows section has no deploy setting.
Use cases#
A team-owned help desk: A support lead builds a help desk workflow in the Support project. Everyone in the support team inherits Member access from the project and can chat with it, while the lead and one colleague are Admins who keep its assistants up to date.Sharing outside the project: A finance analyst builds a reporting workflow in their own project. To let the sales managers use it without giving them access to the rest of the project, the analyst adds the sales managers' team to the workflow as Member.Builders who don't manage access: A Global Admin gives a group of analysts a Permission Set that allows creating and editing only the workflows they own. Each analyst can build and maintain their own workflows, but can't change anyone else's.FAQs#
Can I transfer ownership of a workflow?#
No. The Owner role is assigned to the person who created the workflow and can't be transferred or removed from the access settings.Why can't someone edit a workflow even though I made them an Admin?#
The Admin role only names the workflow. The person also needs a Permission Set that allows editing workflows. Ask a Global Admin to check their Permission Sets.Who can see a workflow's access settings?#
Only its Owner and Admins. Members can't open the access settings. 