--- title: Roles and permissions description: The four workspace roles and exactly what each one can and cannot do. section: Workspaces and access order: 1 --- # 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](/docs/workspaces-and-access/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](/docs/workspaces-and-access/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](/docs/workspaces-and-access/board-access). ## Ownership is not a dropdown 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](/docs/administration/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](/docs/workspaces-and-access/invitations) and [Members and offboarding](/docs/administration/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.