--- title: Members and offboarding description: Changing roles, deactivating or removing people, and what happens to their tickets, keys and seat. section: Administration order: 1 --- # 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](/docs/workspaces-and-access/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? | | Deactivate | Remove | | ------------------------------------------- | ---------------- | --------------------------- | | Access to the workspace | Ends | Ends | | Their API keys in the workspace | Stop working | Stop working | | Signed out of every device | Yes | Yes | | Board access | Cleared | Deleted | | Ticket assignments | **Kept** | **Deleted** | | Pending invitation to that address | Kept | Revoked | | Tickets, comments, wiki edits they authored | Kept | Kept | | Seat charged for | No | No | | Reversible | Yes — reactivate | No — re-invite from scratch | 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](/docs/workspaces-and-access/invitations) and [Billing](/docs/administration/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](/docs/administration/export-and-deletion). ## Using the API Session tokens only — `/admin` does not accept API keys. | Action | Call | | ------------------------------------------ | ---------------------------------------------------------------------------------------------------- | | List members, their roles and board access | `GET /admin/workspaces//users` | | Change role, active status and boards | `PATCH /admin/workspaces//users/` with `role`, `is_active`, `board_uuids` | | Remove someone | `DELETE /admin/workspaces//users/` | | Transfer ownership | `POST /profile/transfer-workspace/` with `user_uuid` | | Review what changed | `GET /admin/workspaces//audit-log` | 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.