Members and roles
The four roles, what each one can do, and how membership is changed.
Everyone in a workspace holds one of four roles. Roles live at Settings, Members.
The four roles
| Role | What it adds |
|---|---|
viewer | Read anything in the workspace. |
editor | Everything a viewer can do, plus ordinary writes. |
admin | Everything an editor can do, plus bulk updates, configuration deletes and workspace administration. |
owner | Everything an admin can do. The two differ only in workspace administration. |
Roles are cumulative. Each one contains the one below it.
The permission matrix
| Capability | viewer | editor | admin | owner |
|---|---|---|---|---|
| Read anything | yes | yes | yes | yes |
| Create and update tickets, replies, notes, time logs, todos, customers, teams, macros, SLA policies, saved views, squads, channel connections | no | yes | yes | yes |
| Apply a macro to a ticket by hand | no | yes | yes | yes |
| Bulk ticket update | no | no | yes | yes |
| Delete teams, macros, SLA policies, squads, saved views, customers, channel connections | no | no | yes | yes |
| Members, invitations, API keys, audit log, billing, security, workspace settings | no | no | yes | yes |
For every helpdesk capability, admin and owner are identical. The one
place they differ is granting roles, covered below.
Bulk update deserves the callout. It sits above ordinary ticket editing, so an editor gets the per-row menu on the queue, which changes one ticket, and does not get the bulk toolbar's actions. Two different questions, because the service asks two.
How the check works
Your role is read from your workspace membership record on every request, never taken from anything the client sends. A role change takes effect on your next request. There is nothing cached and no session to wait out, so a demotion is immediate.
Where the product hides a control from you, it hides it because the service would refuse the call underneath. Where a whole surface is unavailable, you get a notice saying which permission is missing rather than a screenful of dead buttons.
Three different refusals
Worth knowing, because they mean different things:
- 401 means no identity could be resolved on an operation that writes.
- 403 means you are a member, and your role is below what this operation needs.
- 404 means the thing is in another workspace, or you have no membership here. Existence is never disclosed across a workspace boundary, so a 404 does not tell you whether the row exists somewhere else.
Role against account status
These are two different fields and the members list shows both.
Role is what you may do in this workspace. Status is about the account itself. A suspended member keeps their role and cannot use it.
Changing someone's role
Admin only, from the role picker on the members list.
Two guards apply:
- You cannot grant a role above your own. An admin cannot make somebody an owner. The attempt is refused, not partly applied.
- The last owner cannot be demoted, so a workspace can never be left with nobody able to administer it.
Removing someone
Admin only. Removing a member takes away their access here from their next request onwards. It does not delete their account, and it does not touch their membership of other workspaces.
Three things happen alongside:
- their sessions are revoked immediately,
- their memberships of this workspace's teams go with them, so an SLA breach no longer notifies somebody who has left,
- every API key they minted stops working, because a key borrows its owner's live role and there is no longer one to borrow. See API keys.
Tickets they worked keep their name on the timeline.
The last owner cannot be removed.
Who is not on this list
Someone invited but not yet joined does not appear in Members. Invitations are a separate list on the same screen. See Inviting people.