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#

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.

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/<workspace-uuid>/users/<user-uuid> with role, is_active and board_uuids — session tokens only, owner or admin.
• GET /admin/workspaces/<workspace-uuid>/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/<workspace-uuid>/boards returns the boards the caller can reach, so it is also the quickest way to confirm what a key or account holds.