Members and offboarding#

Everything here lives in Admin → People, and needs the owner or admin role. Anyone else gets 403 {"error": "Admin access required."}.

Change someone's role#

Open their row, pick a new role, save. The change takes effect immediately — including for any API key they hold, which always carries its owner's current access.

Three rules to know before you save:

• The save replaces role, active status and board access together. Whatever is on screen when you save is what they will have. If you are only changing a role, leave their boards ticked, or you will strip their board access at the same time. The same applies to the API: PATCH requires role, is_active and board_uuids on every call, and board_uuids is a replacement, not an addition.
• You cannot edit your own row. 400 {"error": "You cannot change your own access."}. Ask another admin, or the owner.
• You cannot edit the owner's row. 400 {"error": "Transfer ownership before changing the owner’s access."} Ownership moves only by transfer.

Promoting someone to admin gives them every board in the workspace at once, so their individual board grants stop mattering. Demoting an admin back to member leaves them with whatever boards are ticked at the moment you save — which, if you have just cleared the list, is none.

Role changes are recorded in the audit log as member.role_changed, with the old and new role.

Deactivate someone#

Deactivating switches an account off in this workspace but keeps the record. Use it when someone leaves, goes on long leave, or you need access stopped now and tidied up later.

The moment you deactivate someone:

• They lose all access to the workspace. Its boards, tickets and wiki are gone from their view, and the workspace disappears from their switcher.
• Their board access in this workspace is cleared. Reactivating them does not restore it — you re-tick the boards as part of the same save.
• Their API keys in this workspace stop working, immediately and without needing to be found or revoked individually. This is the single most useful property of deactivation. See API keys.
• They are signed out. Every device holding a session for that account is signed out on its next request — not only in this workspace, but everywhere, including any other workspace they belong to. They can sign back in, and their other workspaces work normally; this workspace does not.
• They stop counting as a seat, and the new count goes to Stripe straight away.

Their tickets, comments, assignments and wiki edits are all untouched. Their name still appears on the work they did.

Reactivating is the same screen: set them active again, choose their role, tick their boards, save. Their seat comes back with them.

Remove someone#

Removing deletes the membership rather than switching it off. Use it when the relationship is over and you want no trace of access left behind.

Removal does everything deactivation does, and additionally:

• Deletes their board access for the workspace.
• Unassigns them from every ticket in the workspace. This is not reversible. Tickets keep their history, but the assignee is gone, so re-add them to anything that still needs an owner before you remove.
• Revokes any pending invitation to that address for this workspace.
• Leaves nothing to reactivate. Bringing them back means a fresh invitation, and their board access and assignments start from nothing.

What survives removal: tickets they created, comments they wrote, and wiki page versions they authored. That is history, not access, and deleting it would tear holes in your boards and your wiki.

Removal is recorded as member.removed.

Deactivate or remove?#

When in doubt, deactivate. It stops everything that matters just as fast, and it is the one you can undo.

Neither action can be aimed at yourself (400 You cannot delete yourself from the workspace.) or at the owner (400 Transfer ownership before removing the owner.).

Seats and the bill#

Seats are counted from active memberships in billable roles — owner, admin and member. Viewers are free and never counted.

Deactivating or removing someone recounts the seats and sends the new number to Stripe as it happens, not on a nightly sweep. Changes are prorated: removing someone mid-cycle credits the unused days, and adding someone charges only the days they will use. On the annual plan that proration is the difference between paying for a seat and paying for ten months of a seat nobody used.

Changing someone's role between billable roles — admin to member, say — does not change the seat count. Changing them to or from viewer does.

Note that pending invitations to admins and members also hold seats. See Invitations and Billing.

Transfer ownership#

A workspace has exactly one owner, and only the owner can change the subscription, rename the workspace, or delete it. Before an owner leaves the company — or deletes their own account — ownership has to move.

From the owner's account, transfer to any active member of the workspace. On success:

• They become the owner, with billing control.
• You become an admin. You keep running the workspace day to day, but you can no longer manage the subscription or delete the workspace.
• The transfer is recorded as workspace.ownership_transferred.

The transfer is refused if the person you name is not an active member of the workspace, or if you are not the owner.

An owner who tries to delete their own account while still owning a workspace that has other active members in it is stopped with a 409 listing those workspaces. Transfer first, then delete. See Exports and deletion.

Using the API#

Session tokens only — /admin does not accept API keys.

Read the members list before you PATCH: it returns each person's current board_uuids, which you will need to send back unless you intend to change them.