--- title: Board access description: How board membership works alongside workspace roles, and what someone can see when they are not on a board. section: Workspaces and access order: 3 --- # Board access Reaching a board takes two things: an active membership of the workspace, and access to that particular board. The workspace role decides how the second one is satisfied. ## Who reaches which boards | Role | Which boards they reach | | ------ | ------------------------------------------- | | Owner | Every board in the workspace, automatically | | Admin | Every board in the workspace, automatically | | Member | Only the boards they have been added to | | Viewer | Only the boards they have been added to | Owners and admins are never added to boards individually — their role is the grant. Adding or removing a board for an admin changes nothing, and promoting someone to admin gives them every board immediately. Members and viewers hold explicit per-board access. It is set when they are invited, and changed afterwards from **Admin → People**. Board access controls _reach_, not _permission to write_. A viewer added to a board can read it and nothing more; see [Roles and permissions](/docs/workspaces-and-access/roles-and-permissions). ## What a board you cannot reach looks like It is invisible rather than forbidden: - It does not appear in the board list. The list is filtered to boards you can reach, so a member with access to one board out of six sees one board. - Opening it directly answers `404 {"error": "Board not found."}` — the same answer as a board that does not exist. We do not tell you that a board you cannot reach exists, and we never answer 403 for one. That 404 is worth remembering when an API call that works for an admin fails for a member: the usual cause is missing board access, not a broken identifier. ## Tickets follow the board Everything on a board inherits the board's access. Tickets, comments, attachments, statuses, groups and sprints are all reachable exactly when the board is. That extends to searching, listing and polling: a ticket on a board you cannot reach never appears in your results, and a request naming it answers 404. It also extends to mentions — the people you can mention on a ticket are the people with access to that board. ## The wiki is workspace-wide The wiki does **not** follow board access. Every active member of the workspace — including members and viewers with access to no boards at all — can read every wiki in the workspace and its pages. Writing to the wiki still needs a writing role. If something must not be visible to part of the workspace, keep it on a restricted board, not in the wiki. ## The people list is workspace-wide too Any active member can list the workspace's members, whatever boards they hold. Board access hides content, not colleagues. ## Granting and removing board access From **Admin → People**, open someone's row and tick the boards they should have. The save replaces their whole board list for the workspace, rather than adding to it. Whatever is ticked when you save is exactly what they will have — so if you are changing only their role, leave their existing boards ticked or you will remove them. Two consequences worth knowing: - **Deactivating someone clears their board access.** Reactivating them does not bring it back; you re-grant the boards as part of the same save. - **Removing someone deletes their board access** along with their membership. ## Boards you create Whoever creates a board is given access to it as part of the creation. For an admin or owner that changes nothing — they already reach every board. For a member it means a board they create is theirs to work in immediately, and other members see nothing until they are added. There is no self-service "request access" flow. An owner or admin has to add someone. ## Sprint boards When a sprint board rolls over into the next sprint, board access carries over: everyone who could reach the previous sprint's board can reach the new one. ## Using the API Board access is managed as part of a person's access record: - `PATCH /admin/workspaces//users/` with `role`, `is_active` and `board_uuids` — session tokens only, owner or admin. - `GET /admin/workspaces//users` returns every member with their role and current `board_uuids`, plus the workspace's boards. Read it first if you intend to preserve the existing list. - `GET /workspaces//boards` returns the boards _the caller_ can reach, so it is also the quickest way to confirm what a key or account holds.