---
title: Workspaces and boards
description: How workspaces contain boards and boards contain tickets, how board access sits alongside workspace roles, and what the wiki belongs to.
section: Concepts
order: 1
---

# 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

```text
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](/docs/workspaces-and-access/roles-and-permissions)
and [Invitations](/docs/workspaces-and-access/invitations).

### Role and access answer different questions

They combine, and neither substitutes for the other:

|            | Can reach board A              | Cannot reach board A            |
| ---------- | ------------------------------ | ------------------------------- |
| **Member** | reads and writes board A       | board A does not exist for them |
| **Viewer** | reads board A, changes nothing | board A does not exist for them |

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](/docs/wiki/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](/docs/boards-and-tickets/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](/docs/troubleshooting/errors).