Roles and permissions#
Everyone in a workspace holds exactly one role: owner, admin, member, viewer, commenter, or one of the two guest roles. The role decides what they can change, whether they can reach the admin screens, and whether they cost you a seat.
Roles are per workspace. The same person can be an admin in one workspace and a viewer in another, and each workspace bills separately.
The roles at a glance#
- Owner — one per workspace, the person who created it or had it transferred to them. The only role that can spend money or delete the workspace.
- Admin — runs the workspace day to day: invites people, sets roles, manages board access and API keys. Reaches every board.
- Member — the ordinary working role. Can create and change content, but only on the boards they have been added to.
- Viewer — read-only. Free. Never charged for, never counted against your seat limit.
- Commenter — a viewer who may also comment. Reads what a viewer reads and posts comments on tickets it can already see; it can change nothing else, not a title, not a status, not a label. Workspace-wide like a viewer rather than board-scoped like a guest, and free on the same terms.
- Guest (view only) — an outsider on named boards. Reads those boards and nothing else in the workspace. Free.
- Guest (can edit) — the same reach, plus the ability to work in those boards. Costs a seat, exactly like a member.
What each role can do#
Six columns, not seven: commenter is the viewer column exactly, plus the one ability to post a comment on a ticket it can already see. Read the Viewer column and add that, rather than looking for a column that would repeat it.
| Capability | Owner | Admin | Member | Viewer | Guest (view only) | Guest (can edit) |
|---|---|---|---|---|---|---|
| Read the boards they are added to | Yes | Yes | Yes | Yes | Yes | Yes |
| Reach every board in the workspace | Yes | Yes | No — only boards they are added to | No — only boards they are added to | No | No |
| Read the wiki | Yes | Yes | Yes | Yes | No | No |
| List the workspace's people | Yes | Yes | Yes | Yes | Only people on their boards | Only people on their boards |
| Create and edit tickets on their boards | Yes | Yes | Yes | No | No | Yes |
| Create boards, labels, wikis or wiki pages | Yes | Yes | Yes | No | No | No |
| Delete or copy a board, or start a sprint series | Yes | Yes | Yes | No | No | No |
| Open the admin screens (People, Invitations, API keys, Audit log) | Yes | Yes | No | No | No | No |
| Invite people and choose their role | Yes | Yes | No | No | No | No |
| Change a role, deactivate or remove someone | Yes | Yes | No | No | No | No |
| Grant or remove board access for someone else | Yes | Yes | No | No | No | No |
| Create an API key for themselves | Yes | Yes | Yes | Yes | Yes | Yes |
| Revoke anyone's API key in the workspace | Yes | Yes | Own keys only | Own keys only | Own keys only | Own keys only |
| See the billing summary (plan, seats, renewal date) | Yes | Yes | Yes | Yes | No | No |
| Start, change or cancel the subscription; open the Stripe portal | Yes | No | No | No | No | No |
| Rename or delete the workspace | Yes | No | No | No | No | No |
| Transfer ownership | Yes | No | No | No | No | No |
| Can be made owner or admin | — | Yes | Yes | Yes | No — make them a member first | No — make them a member first |
| Counts as a billable seat | Yes | Yes | Yes | No | No | Yes |
Guests see the workspace as if it were only their boards#
A guest is for somebody outside the company — a client, a contractor, an auditor — who should see the work on one or two boards and have no idea what else is in the workspace. On top of the board access members and viewers have, a guest additionally cannot:
- list the workspace's people. The members list a guest reads holds only the people it shares a board with; everyone else reads exactly as if they did not exist
- read any wiki, wiki page, or wiki result in ⌘K search, whatever the page's visibility
- read the trash, the workspace labels, the board templates, or the billing summary
- reach the admin screens
A guest who can edit works its own boards — tickets, comments, attachments, columns, groups — and nothing else. Creating a board, a label, a wiki page or an invitation is refused, as is deleting or copying one of its own boards:
{
"error": "A guest can only work in the boards they have been given."
}
The status is 403, and the wording never names a board: a guest is not told whether the board it asked about exists.
A guest cannot be promoted straight to admin, and cannot be made the owner. Both of those roles reach every board in the workspace, so the step is deliberate — make them a member first, which grants workspace-wide access and takes a seat, and promote from there.
A guest who can edit is a seat; a guest who only reads is free#
The split is the same one viewers and members have, one rung narrower: what you pay for is the ability to write. Changing somebody from a view-only guest to a guest who can edit takes a seat the moment you save it, and is refused with a 402 if the plan has none left. Changing them back releases it.
Two things in the capability table catch people out:
- Admins cannot touch billing. Only the owner can start a subscription, change
the card, or cancel. Everyone else — admins included — gets
403 {"error": "Only the workspace owner can manage billing."}. They can still read the billing summary. - Admins cannot delete the workspace. That is the owner's alone.
Viewers are read-only and free#
A viewer can open every board they have been added to and read everything on it: tickets, comments, attachments. They cannot change any of it.
The wiki is the exception: a viewer reads every wiki in the workspace whether or not they hold any board at all, because the wiki does not follow board access — see Board access.
A viewer never counts as a billable seat. Inviting one is never refused by a seat limit, and adding one never changes your invoice. That is deliberate — read-only access is the cheapest way to give a client, a stakeholder or an auditor a window into the work.
Exactly what a viewer cannot do#
Viewers are blocked from every write to boards, tickets, wiki pages, wiki content and workspace settings such as labels. In practice that means they cannot:
- create, rename, archive or reorder a board, or change its columns
- create, edit, move, assign, archive or delete a ticket
- comment on a ticket, or upload an attachment
- create or edit a wiki page
- create, edit or delete a workspace label
Any of those attempts is refused with:
{
"error": "Your role in this workspace is read-only."
}
The HTTP status is 403. The wording is identical whichever thing was being written, so if you see it, the answer is always the same: the account needs to be a member, not a viewer.
Viewers can still create an API key for themselves — but the key acts as them, so it is a read-only key. See API keys.
Members see less than admins#
Owners and admins reach every board in the workspace automatically. Members and
viewers reach only the boards they have been added to; a board they have not been
added to is not listed for them, and opening it directly answers
404 {"error": "Board not found."} rather than a 403 — we do not confirm that a
board they cannot reach exists.
The full rules, including how this interacts with tickets and the wiki, are on Board access.
Ownership is not a dropdown#
The role picker offers admin, member, viewer and the two guest roles. Ownership moves through a deliberate transfer instead, and the outgoing owner becomes an admin. Attempting to edit the owner's row answers:
{
"error": "Transfer ownership before changing the owner’s access."
}
See Members and offboarding for how to transfer.
Changing someone's role#
Roles are set when you invite someone, and changed afterwards from the admin screens. Both are covered in Invitations and Members and offboarding.
Changing a role takes effect immediately, including for any API key that person already holds — a key always carries its owner's current access, never the access they had when the key was made.