Workspaces and boards#

Laver has one containment model and it does not bend. Understanding it explains most of what the product will and will not let you do.

The containment model#

workspace
  ├── board
  │     ├── status column
  │     └── ticket
  ├── wiki
  │     └── page
  └── labels

A workspace is the tenant. It owns the people, the subscription, and everything created inside it. Nothing is shared between workspaces: not a board, not a ticket, not a person's role, not a label. Belonging to two workspaces means holding two separate memberships that know nothing about each other.

A board belongs to exactly one workspace and holds two things of its own: its status columns, and its tickets. Columns are per-board, so renaming a column on one board changes nothing anywhere else.

A ticket belongs to exactly one board, and sits in one of that board's columns. It can be moved to another board in the same workspace, which also moves it into a column on the new board. It cannot leave the workspace.

Labels are the exception to per-board ownership: they are defined once for the workspace and can be applied to any ticket on any board in it.

Board access sits alongside workspace roles#

Every person in a workspace has exactly one workspace role: owner, admin, member, or viewer. That role decides what they may do. A second, separate list decides where they may do it: which boards they can see at all.

The rule is short:

• Owners and admins reach every board in the workspace, including boards created after they joined, and boards created by other people. There is no way to hide a board from a workspace admin.
• Members and viewers reach only the boards they have been given. A board they have not been given does not appear in their sidebar, and requests for it answer "Board not found." rather than "forbidden" — they are not told it exists.

Board access is granted in two places, both of them owner/admin only:

• On the invitation, with the Board access checkboxes, when the person is invited as a member or viewer. Choosing Admin disables the checkboxes, because an admin gets everything.
• Afterwards, on User access → People, by editing the Board access checkboxes on that person's row.

See Roles and permissions and Invitations.

Role and access answer different questions#

They combine, and neither substitutes for the other:

A viewer with access to every board still cannot move a ticket. A member with access to no boards can log in and see nothing but the wiki.

Creating a board grants access only to its creator#

Members can create boards, and when they do, they are the only non-admin who can see the new board. Owners and admins see it automatically because they see everything.

This surprises teams: a member spins up a board, tells a colleague about it, and the colleague cannot find it. The fix is for an owner or admin to tick the board on that colleague's row in User access. There is no request-access flow and members cannot grant board access, including to boards they created.

One related effect: on a given board, the people you can @-mention are the workspace admins plus the members and viewers who have that board. Someone who cannot open the board is not offered as a mention on it.

What a wiki belongs to#

The wiki belongs to the workspace, not to a board.

That is deliberate: the things worth writing down — how the team works, what was decided, how to run something — rarely belong to one board, and pinning them to one would hide them from everyone who has a different board.

The consequence is that board access does not restrict the wiki. Anyone with an active membership in the workspace can read every wiki page in it, including a member who has been given a single board, and including viewers. Writing follows the workspace role in the usual way: owners, admins, and members can write pages, viewers cannot.

A workspace is created with one wiki, named Wiki, and more can be added. See Wiki pages.

What a board is made of#

Beyond its columns and tickets, a board carries:

• A name and a position in the sidebar, both editable — drag boards to reorder them.
• Card display preferences — which of priority, assignees, due date, and cover image show on cards, plus up to four hover shortcuts. These are yours: they are stored per person, so changing them does not change what anyone else sees.
• Sprint settings, if the board has been turned into a sprint series. See Sprints.

Deleting a board archives it: it disappears from the sidebar for everyone and its tickets go with it. There is no undo in the app.

Subscription state applies to the whole workspace#

Because billing belongs to the workspace, its state applies to every board and the wiki at once. A workspace with no live subscription is closed to reading as well as writing, whatever anyone's role; a workspace whose invoice has gone unpaid may go read-only, which keeps everything readable and exportable and refuses writes. Neither state deletes anything. What you see when it happens is in Common errors.