Workspaces and access

Roles and permissions#

Everyone in a workspace holds exactly one role: owner, admin, member or viewer. 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 four 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.

What each role can do#

Capability	Owner	Admin	Member	Viewer
Read boards, tickets and the wiki	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
Create and edit boards, tickets, labels and wiki pages	Yes	Yes	Yes	No
Open the admin screens (People, Invitations, API keys, Audit log)	Yes	Yes	No	No
Invite people and choose their role	Yes	Yes	No	No
Change a role, deactivate or remove someone	Yes	Yes	No	No
Grant or remove board access for someone else	Yes	Yes	No	No
Create an API key for themselves	Yes	Yes	Yes	Yes
Revoke anyone's API key in the workspace	Yes	Yes	Own keys only	Own keys only
See the billing summary (plan, seats, renewal date)	Yes	Yes	Yes	Yes
Start, change or cancel the subscription; open the Stripe portal	Yes	No	No	No
Rename or delete the workspace	Yes	No	No	No
Transfer ownership	Yes	No	No	No
Counts as a billable seat	Yes	Yes	Yes	No

Two things in that 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:

json

{
    "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.

The role picker offers admin, member and viewer only. Ownership moves through a deliberate transfer instead, and the outgoing owner becomes an admin. Attempting to edit the owner's row answers:

json

{
    "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.