Roles and permissions
Every member of an organization holds exactly one role. This page lists what each role can do, so you can pick the right one when inviting someone or reconsider one later.
Beyond the four built-in roles, you can create your own custom roles with a tailored set of permissions when none of the built-in roles fits.
Roles apply per organization. Someone who belongs to two organizations can be an Admin in one and a Viewer in the other.
The four roles
| Role | For |
|---|---|
| Viewer | Someone who needs to see what is happening without changing it. |
| User | Someone who builds and runs deployments day to day. |
| Admin | Someone who runs the organization: its people, its hosts, and its billing. |
| Owner | The person who created the organization. |
Owner is not assignable. It belongs to whoever created the organization and cannot be granted, changed, or removed from the Team page.
What each role can do
Owner has every ability an Admin has, plus a few organization-level actions that never surface in the app, such as deleting the organization. The Owner is also a protected role, described under Owner is a protected role below.
| Viewer | User | Admin | Owner | |
|---|---|---|---|---|
| View workflows, hosts, deployments, and files | Yes | Yes | Yes | Yes |
| Create, edit, and delete workflows | No | Yes | Yes | Yes |
| Run a deployment | No | Yes | Yes | Yes |
| Build and edit components | No | Yes | Yes | Yes |
| Cancel a running deployment | No | No | Yes | Yes |
| Register, edit, and remove hosts, and revoke their desktop agent credentials | No | No | Yes | Yes |
| Invite, re-role, and remove members | No | No | Yes | Yes |
| Approve or decline join requests | No | No | Yes | Yes |
| Edit the organization's name and description | No | No | Yes | Yes |
| Disable or re-enable the organization | No | No | Yes | Yes |
| Read and manage webhooks | No | No | Yes | Yes |
| Manage billing and change plans | No | No | Yes | Yes |
| Manage organization secrets | No | No | Yes | Yes |
| See what a managing organization changed | No | No | Yes | Yes |
| See and end the partnership with a managing partner | No | No | Yes | Yes |
Editing is organization-wide, not personal. A User can edit and delete any workflow or component in the organization, not only the ones they created. If you need someone who can look but not touch, that is the Viewer role.
Creating a new organization is not restricted by role. Any signed-in member can start one and becomes its Owner, as long as their plan allows another organization.
Custom roles
The four built-in roles cover most teams, but you can also create your own roles with a tailored set of permissions. Reach for a custom role when none of the built-in roles fits. A "Deployment Operator" who can run and cancel deployments but cannot touch hosts, billing, or membership is a good example.
Custom roles are managed on the Roles page under Settings. You need the Owner role, or a custom role that includes role management, to see it.
Create a custom role
- 1
Open the Roles page
Select Settings in the sidebar, then Roles.
- 2
Start a new role
Select Create role, then give it a name and an optional description. The name is what appears in the role dropdowns when you invite or re-role a member.
- 3
Choose its permissions
Tick the permissions the role should grant. They are grouped by area, such as workflows, hosts, and deployments. Only organization-level permissions are offered.
- 4
Save
Select Create. The role is now available everywhere you assign roles.
Editing works the same way: select Edit on a custom role to rename it or change its permissions. Changes take effect immediately for every member who holds the role.
What a custom role can grant
A custom role grants only organization-level permissions, the same kinds of actions the built-in roles are built from: viewing and managing workflows, hosts, deployments, components, files, and webhooks.
It can never grant privileges that reach beyond your organization or that could escalate control of it. These are deliberately not offered to a custom role:
- System administration, or anything global to the platform.
- Billing and plan changes.
- Creating or deleting the organization.
- Managing roles themselves, so a custom role cannot grant itself more power.
- Managing other members' multi-factor authentication.
The result is a safe subset. A custom role can tailor what members do inside your organization without ever widening the blast radius past it.
Because the permission list is fixed to this safe subset, you cannot build a custom role that acts like a system administrator. If a permission is not in the list on the Roles page, no custom role can hold it.
Assign a custom role
Custom roles appear alongside the built-in ones wherever you pick a role: the invitation dialog, the member role dropdown on the Team page, and the add-member dialog. Assign one exactly as you would Viewer, User, or Admin.
Delete a custom role
Select the delete control on a custom role to remove it. A role that is still assigned to one or more members cannot be deleted, so reassign those members to another role first, then delete it. Built-in roles cannot be deleted.
Owner is a protected role
The Owner is whoever created the organization. The role is not in the dropdown when you invite someone or change a member's role, and it cannot be reassigned from the Team page.
The Owner also cannot be removed from the organization or have their role changed by anyone, including an Admin. Their badge on the Team page carries a (Protected) marker.
This guarantees the organization always has one member who cannot be locked out by another.
Choosing a role
Start people at User unless you have a reason not to. It covers building and running deployments, which is what most members do, and it withholds the things that affect everyone: hosts, membership, and billing.
Use Viewer for people who need visibility without the ability to change anything, such as a stakeholder watching deployment results.
Keep Admin small. An Admin can change your plan, remove other members, and edit the organization itself.
Protections that apply to everyone
Some restrictions are built in and are not part of any role:
- You cannot change your own role.
- You cannot remove yourself from an organization on the Team page.
- The Owner's role cannot be changed and the Owner cannot be removed.
These prevent an organization from being left with nobody who can administer it.
Organizations managed by a partner
If a partner manages your organization, the partner controls its plan and billing, and nobody in your organization holds the Owner or Admin role. The partner can give your own staff the Client Admin role, which runs your team, single sign-on, secrets, and workloads, without access to billing or deleting the organization.
People from the partner can also work inside your organization. They act as themselves, not as one of your members, and never with access to your billing or to deleting the organization. If the partner's account is suspended, their access to your organization is read-only. If the partner stops billing for your organization or releases it, they can no longer work inside it.
Client Admins can also see the partnership and end it by subscribing your organization to a plan of its own, on the Partner tab under Settings, then This Organization. The partner can include this permission in a custom role too, but people from the partner never have it inside your organization. See Your partner.
The partner can also push workflows and components to your organization, and anyone who can edit them can revert the partner's last update. See Updates from your partner.
Everything the managing organization does to yours is recorded. Owners, Admins, and Client Admins can review it by opening Settings, then This Organization, then the Partner Activity tab: creating the organization, setting or changing its plan, enabling or disabling it, inviting or removing members, changes to its partner billing, and each time someone from the partner opens it (Opened this organization) along with the recorded actions they take inside. Each entry shows when it happened, what changed, and the person and organization who did it. It does not include their email address or where they signed in from.
Related
- Managing your team for the tasks themselves.
- Plan limits and usage for how many members your plan allows.