Skip to main content
A role decides what a teammate can see and change in this workspace. Every workspace starts with the same three (Admin, Member and Viewer) and you build any others yourself, by ticking boxes in a Create/Read/Update/Delete grid.
Where
Settings→Roles & Permissions
Your role needs
Read access to Roles & Permissions read-roles. Admin have it by default.
If you cannot find this in your sidebar, your workspace may have a custom menu configuration. Contact support and we will check it for you.
Three system roles and one custom role look like this:

​
How it behaves

​
The three system roles are shared, and nobody edits them

Admin, Member and Viewer are shared definitions, attached to your workspace rather than built for it: one Admin, one Member, one Viewer, the same three grids in every workspace on the product. That is why none of them can be edited or deleted. Opening one shows its grid for reference, with every checkbox disabled and a Duplicate as custom role button in the footer where Save would be. The refusal is not only on screen: the server rejects an edit or a delete of a system role for everyone, our own staff included. Member and Viewer are seeded with read access to the workspace itself, the teammate list and the subscription balance so the app can load for them at all: a floor underneath whatever else either role holds. A fourth system role exists above these three, for our own staff. It belongs to no workspace, it is never listed on this screen, and nothing in the product can assign it to anyone in yours.

​
Roles are ranked, and the ranking does one thing

The three system roles are ranked against each other (Admin over Member, Member over Viewer) and every custom role you build ranks below all three. That ranking is used in exactly one place: removing a teammate from the workspace requires your own role to rank at or above theirs. So a custom role you gave delete access to teammates still cannot remove someone holding Admin, Member or Viewer.

​
Duplicating carries the grid across

Duplicate as custom role switches the same dialog into create mode (the title changes to Create role) and pre-fills the name field with the system role’s own name followed by (copy). The permission grid is not reset. Whatever the system role held is still ticked, so duplicating Member and unticking a handful of rows is quicker than building a role from nothing.
Duplicating Admin is the exception. Admin holds impersonation permissions that no workspace role is ever allowed to hold, so they are not drawn in the grid. But they are still carried into the duplicate, invisibly, and saving is refused because of them. Unticking rows does not clear them, and reopening the dialog brings them back. Close it and start from Create role instead.

​
A custom role is a name, a description and a grid

Creating or editing a custom role asks for a Role name (required), an optional Description, and the same Create / Read / Update / Delete grid the system roles show, one row per module: campaigns, leads, email accounts, workflows and so on. A module that grants fewer than four actions shows a dash in the columns it has nothing to offer. The checkbox beside a module’s own name toggles every action it has at once, and sits in a half-ticked state while only some of them are on. That grid is not this page’s to define. It is the same catalogue for every workspace and every editor, and the full list (with what each module grants and which system role already holds it) is on the permission catalogue. Your browser caches it for a few minutes before asking again, since it only changes when the product does. Leaving every box unticked is refused before the request goes out: a role has to grant at least one permission.

​
Saving is checked on the server

The grid you see is not filtered to what you personally hold. Everyone editing a role sees the same catalogue. Overreach is caught on save instead, and the message names exactly what went wrong:
  • A reserved or already-taken name. A short list of names is off-limits, the system roles among them, and no two custom roles in one workspace may share a name. Names are compared after being reduced to lowercase and hyphens, so “Campaign Manager” and “campaign-manager” count as the same name.
  • A permission outside the catalogue. Impersonation permissions can never be granted to a workspace role, whatever the grid contains.
  • A permission you do not hold yourself. You can only grant what your own role already grants you, so an editor with a narrower grid than Admin cannot hand out more than they have.
Each of those comes back as a plain sentence naming the offending name or permissions, shown exactly as the server wrote it rather than replaced with generic copy. A successful save shows a Role saved toast. If the role you just edited is the one you hold, the app refreshes your session straight away, so your sidebar and every permission-gated control follow the new grid without a reload.

​
Deleting is blocked while anyone still holds the role

A custom role’s delete icon disables itself the instant its member count is above zero, with a tooltip naming how many members are holding it: the greyed-out icon marked (1) above. That is a courtesy, not the guard: the server counts the assignments again and refuses the delete for the same reason, and its refusal appears inside the confirmation dialog rather than as a toast. Reassign those members first. Confirming a delete on a role nobody holds asks once more, by name, before it goes. System roles have no delete icon at all; a View icon is the only action on their row. The edit and delete icons on a custom role are themselves gated. A role that can open this screen but holds no update or delete permission on roles sees the rows and no icons.

​
Neither Member nor Viewer holds anything on roles

Member and Viewer hold no permission on the roles module at all, not even read. That is unlike almost everywhere else in the product: Viewer can read campaigns, leads, email accounts, workflows and nearly every other module, and this is the one place it has nothing. A custom role behaves the same way if you did not tick the roles row when you built it. The same denial appears twice below: first a custom role, then the system Viewer: Two different permissions are at work here, and they diverge on the Access tab rather than on this one. The role list loads for anyone holding read access to roles, or update or create access to teammates. Someone who can invite people or change their role needs the list to fill the role picker, even though they cannot open this screen. The permission catalogue behind the grid loads only for read access to roles. Elsewhere in the product, a control your role cannot use is usually not drawn at all. The button is gone rather than greyed out. A few that anchor a layout stay visible and inert, with a tooltip explaining why. Roles & Permissions is neither: the route itself sends you somewhere else.
A session cached from before permissions shipped is allowed everything until it refreshes, which is why none of this is the real guard. Hiding and disabling controls is presentation; the server authorises every request on its own.

​
Limits

Permissions reference

The full grid module by module, with what each system role holds out of the box.

Invite team members and manage access

Send the invite, pick the role, and change it later from the Access tab, not from here.

Permission catalogue

Every grantable permission on its own page, generated from the same catalogue this screen reads.