Automation permissions and scopes
Automation directly affects people's work: it changes tasks and deals, schedules steps, and sends emails. That is why access to it is split into levels and tied to a scope. Permissions answer two questions: what a user can do with automation (view, configure, run) and where — in which company, pipeline, or project.
This page explains the permission model so roles are assigned deliberately, not "everyone gets everything."
Why separate permissions
If everyone has full access, automation is easy to break: someone accidentally changes another team's rule, runs a workflow on production data, or reassigns tasks. Separating permissions protects the process: automation is configured by the person responsible for the process, while performers only carry out their steps.
Every automation operation is checked: if the permission is missing, the operation does not run, and the response shows a denial reason code (the same one is visible in the run history).
Permission levels
Access to automation is divided into levels:
- view — see rules, robots, guards, and workflows, but not change them;
- manage — create and edit automation;
- run — go through preview and simulation, run manually, and process "due steps to run";
- assignment — address manual tasks to people and receive them.
The levels are independent: you can have view without manage, or the ability to perform tasks without the permission to change templates.
View
The view permission gives access to automation lists and history, but not to changes. This is the basic level for a manager who controls what is enabled and how it works, but does not configure rules themselves. Without the view permission, the corresponding section or row is unavailable.
Manage
The manage permission lets you create and edit automation: task rules, CRM robots, operation guards, templates, and workflows. This is the workflow owner's level. Manage in one scope does not grant permissions in another: someone who configures robots for one pipeline does not necessarily manage automation for the whole company.
Run
The run permission is separate from manage. It lets you go through a rule's preview, a workflow simulation, run automation manually, and process "due steps to run". This way you can give an employee the ability to safely check and run automation without opening template editing to them.
Assigning and receiving tasks
Separate permissions govern workflow manual tasks: who can address a task to people and who can receive it. This matters for the workflow audience: a task should reach only the people it is meant for. Check that the recipients are the right employees, not a broader group.
Scopes
Permissions are tied to a scope. Automation and guards can operate at the level of:
- company — a shared standard for everyone;
- department — for a specific unit;
- pipeline or stage — for part of the sales process;
- project — for a specific client context.
A permission in a narrow scope does not extend to a broad one: managing automation for one pipeline does not grant company-level permissions. Grant permissions in the minimally sufficient scope — this reduces the risk of accidental changes.
Read-only and denials
If a role lacks the permission for an action in the required scope, automation is shown as "read-only," and the operation returns a denial with a clear reason. This is not an error — it is the access model working. When the action you need is unavailable, first check the permission level and the scope the automation belongs to, rather than working around the restriction.
Good practices
- Grant permissions by role: workflow owner, manager, performer.
- Separate manage and run — not everyone who runs needs editing.
- Limit a permission's scope to the minimally sufficient one.
- Check the audience of manual tasks so steps do not go to extra people.
- Resolve denials by reason code instead of granting full access "to make it work."
Common mistakes
Giving everyone manage. Other teams' rules get changed by accident, and the process breaks.
Confusing run with manage. An employee only needs a run, but editing is opened to them.
A permission scope that is too broad. Access to the whole company's automation where one pipeline would have been enough.
Working around a denial instead of resolving it. The denial reason points directly to which permission or scope is missing.
How to check permissions
- the needed automation sections are visible under the user's role;
- manage is available only where the role is responsible for the process;
- run and simulation work without the editing permission, if that is intended;
- manual tasks reach only the target audience;
- denials are explainable by reason code and match the permission's scope.