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. The one board their role does not reach is a private board, which is the point of one.

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.

Guests are the exception to both#

Neither of the two paragraphs above applies to a guest. A guest reaches no wiki at all, and the people list it reads holds only the people it shares a board with. That is the whole difference between a guest and a viewer: a viewer is somebody in your company with nothing to change, a guest is somebody outside it who should not be able to tell what else the workspace contains. See Roles and permissions.

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.

Private boards#

A private board is reached by the people on it, and by nobody else. The workspace's owners and admins are not exempt — their role stops at the door, which is the whole of what "private" means here. It is not a paid feature and anyone who can create a board can create a private one.

Tick Private when you create the board, in the sidebar's New board form. A board created this way starts with one person on it: you.

An existing board can be made private from its ⋯ menu in the sidebar, Make private — but only while you are the only person on it. A board with other people on it is refused, because making it private would take it away from them, and one of them silently locking an owner out of a shared board is not something we let happen. Empty the board's access first if that is really what you want.

Make visible to the workspace in the same menu gives it back, and needs no such condition.

Once a board is private:

• It is not in anyone else's board list, not in their search results, and opening it answers 404 {"error": "Board not found."} — exactly like a board that does not exist. Everything under What a board you cannot reach looks like applies to an owner too.
• Admin → People does not offer it when granting board access, and does not show it in anybody's list of boards. Saving someone's access there leaves their place on a private board untouched, which is also the exception to "the save replaces their whole board list" above.
• It is not in a workspace export taken by someone who cannot reach it, and neither are its tickets, comments or attachments.
• It cannot be published to the web, and a board that already has a public link cannot be made private. Stop sharing it first.
• Notifications about it go only to the people on it.

Adding somebody to a private board is done the same way as any board, from Admin → People — by an owner or admin who is on the board. It stays private with two people on it; "private" is about the role-based grant, not about the number of people.

Two things a private board does not hide. Its name and the fact that it was made private appear in the workspace's audit log, so an owner who has lost sight of a board can see what happened to it and who did it. And it still counts towards the workspace's board limit and its bill.

Publish a board as a read-only roadmap#

Everything above is about people with an account. A board can also be given a public link that anyone can open without one — a client, an investor, or a customer who wants to know what is coming. It is a paid plan feature.

Open ⋯ → Share publicly in the board header and choose Create a public link. Only an owner or admin can reach that page at all: handing somebody the URL is publishing on their behalf.

What the link shows is deliberately thin:

It is read-only, and it is not listed in search engines. Stop sharing kills the link immediately; sharing again afterwards mints a different link, so that is also how you revoke one that reached the wrong person.

User access → Published to the web lists everything in the workspace that is currently readable without a login — boards and wiki pages, who published each one and when — and unpublishes any of it. The switch for the whole workspace is under User access → Settings; turning it off stops every published board at once.

Publishing a single wiki page works the same way and is a separate switch; see Wiki pages.

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. A private sprint board rolls over into a private one, for the same reason.

Every sprint is a board of its own, so the tick-boxes only offer the current sprint of each series — a year of finished cycles would otherwise be a year of boxes. That one box stands for the whole series: tick it and the person is added to the sprints behind it too, so the history is theirs to read from the start. Untick it and they come off all of them.

Naming any sprint of the series over the API — an older one included — grants the series, so board_uuids never has to list them all. GET /admin/workspaces/<workspace-uuid>/users returns the current sprint alone in both the workspace's boards and each person's board_uuids, and each board carries sprint_series_uuid so you can tell which box covers a series. Archiving a sprint leaves its access alone until the board is restored.

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. Each board carries is_private.
• POST /workspaces/<workspace-uuid>/boards accepts is_private: true, and PATCH /boards/<board-uuid> accepts is_private to change it afterwards. Making a board private while somebody else is on it, or while it has a public link, answers 409 with the reason.

An API key acts as the person who created it, so it reaches their private boards and no others.