Roles and permissions
What Owner, Admin, Agent, and Viewer can each do, the primary owner, and how custom roles add permissions on top.
Every staff member holds one of four built-in roles. The role sets a default grant of permissions; custom roles can add more on top. Permissions are always scoped to your workspace, so no one can ever act across organizations.
The four roles
| Role | What it can do |
|---|---|
| Owner | Everything. Full access to every surface and every setting. |
| Admin | Everything, the same full access as Owner. |
| Agent | Work conversations and live chats, use saved replies and tags, moderate feedback, manage the help center, changelog, and work boards, and view analytics. |
| Viewer | Read-only access across the workspace. |
The primary owner
Exactly one member per workspace is the primary owner. On top of full owner access, the primary owner is the only member who can delete the workspace or transfer the primary ownership to someone else. This prevents an ordinary owner or admin from removing the account out from under everyone.
What an Agent can and cannot do
An Agent is your front-line role. Agents can:
- Read and work the inbox: reply, assign, tag, snooze, resolve, add internal notes, and use saved replies.
- Handle live chat: view the queue, accept a chat reserved for them, and work it in real time.
- View the operations analytics dashboard.
- Read and moderate feedback boards, and manage the help center, changelog, and work boards.
Agents cannot change workspace configuration. Configuring live-support settings, routing, SLA policies, boards, request types, workflows, and status-page components stays at Admin and Owner level. Exporting the underlying analytics data is also reserved for Admin and Owner; Agents can view the dashboard but not export.
Viewer
A Viewer sees everything an Agent can see but cannot change anything: it is a read-only grant across the workspace. It suits stakeholders, auditors, or new hires in training.
Custom roles
Beyond the four built-ins, a workspace can define custom roles that carry an explicit list of permission keys (for example, letting a specialist manage the help center without full admin access). A custom role's permissions are added on top of the member's coarse role, never subtracted, so custom roles grant capability rather than restrict it.