Boards#

A board is one kanban wall: a set of status columns with tickets in them. Every board belongs to a workspace, and a workspace can hold as many boards as its plan allows.

Before you start#

• You need a workspace role that can write — owner, admin or member. A viewer can open boards and read everything on them, but every button described here will return "Your role in this workspace is read-only". See Roles and permissions.
• On the free plan a workspace may have 3 boards. Trying to create a fourth is refused with a message naming the limit and the price to lift it. The Pro plan has no board limit. Archived boards do not count, so archiving one frees a slot and restoring it uses that slot again.
• Whoever creates a board is given access to it. Owners and admins see every board in the workspace; members only see boards they have been added to. See Board access.

Create a board#

1. In the left sidebar, click the three dots beside the Boards heading and choose New board.
2. Type a name (up to 200 characters).
3. Leave the picker underneath on Empty board, or choose a template to start from.
4. Click Create board.

Laver opens the new board straight away. Pressing Escape in the name field cancels without creating anything.

If the workspace has no boards at all, the main panel shows No boards yet with a Create a board button that does the same thing.

Starting from a template#

The picker offers two groups. Templates are the ones that ship with Laver — CRM and Sales leads — each with its own columns, labels and a handful of example tickets; the line under the picker says what one is for. Saved from your boards holds the templates this workspace has saved for itself, described by how many columns and tickets they carry.

A template is applied once, when the board is created. From that moment the board is an ordinary board: renaming a column, deleting an example ticket or changing the template later has no effect on the other. There is no way to apply a template to a board that already exists.

What a new board starts with#

Every new board is created with three status columns:

It starts with no tickets, and with you as its only member.

The completion column matters in two places: it is the column the card hover shortcut moves a ticket to by default, and it is what a sprint rollover treats as "finished". See Sprints.

Save a board as a template#

A board you set up once and rebuild every quarter can be kept as a template of the workspace's own.

1. Right-click the board's row under Boards in the sidebar, or click its ⋯ button.
2. Choose Save as template.
3. Give it a name (up to 120 characters, unique in this workspace) and, if the name is not enough, a description of when somebody should pick it (up to 500).
4. Save template. It appears under Saved from your boards in the new-board picker for everyone in the workspace.

What is saved is a snapshot of the board as it stands, not a link to it. Editing the board tomorrow does not change the template, and a board made from the template is not affected by either.

The dialog says the same thing before you press the button. A template carries at most 300 tickets — the oldest by board order, archived and hidden ones excluded — and a board with no columns cannot be saved as one.

To get rid of a template, open the new-board picker, select it, and click Delete "name" underneath. Only the person who saved it, or a workspace owner or admin, can; anyone else is refused. Deleting a template leaves every board made from it alone.

Rename a board#

1. Open the board.
2. Click the pencil (Rename board) next to the board name in the header.
3. Edit the name and press Enter, or click the tick.

Escape or the cross cancels. Names can be up to 200 characters, and ordinary boards are allowed to share a name. The one exception is sprints: a sprint board is named from its series, and creating one is refused if a board of that name already exists.

Give a board a background colour#

Boards can be told apart at a glance by giving each one its own colour.

1. Open the board.
2. Click the three dots (Board actions) at the right of the board header.
3. Choose Board background.
4. Pick one of the eight colours, or use Or pick a colour for anything else. The strip underneath shows how the board will look.
5. Click Save.

To take a colour off again, open the same dialog, choose the crossed-out swatch (No background) and save. The board goes back to following your theme.

Some things worth knowing:

• Only an owner or an admin can set one. The colour belongs to the board, not to you, so everyone who opens that board sees it. Members and viewers do not see the menu item, and the change is refused for them if they try.
• It is mixed into your theme, not painted over it. A tenth of the colour is blended into the board canvas, which is enough to tell two boards apart while leaving cards, columns and text on the colours your theme chose. The same board therefore looks right in light mode and in dark mode, and in whichever of the palettes you picked in Appearance.
• Only the canvas behind the columns is coloured. The board header, the sidebar and the ticket panel keep their usual background.

Reorder boards in the sidebar#

Board order is a property of the board, so the order you set is the order everyone in the workspace sees.

• With a mouse: drag the grip handle at the left of a board row up or down and drop it. A line shows where it will land.
• With a keyboard: focus the grip handle (its label is "Reorder board name") and press Arrow Up or Arrow Down. Each press moves the board one place and saves immediately.

If someone else adds or removes a board while you are dragging, the save is refused with "The board list changed. Refresh and try again."

Archive a board#

Removing a board archives it. The board and its tickets are kept; they are only taken out of the sidebar and out of everyone's way. Nothing is destroyed, and there is no countdown — an archived board is kept until you restore it, or until an owner or admin deletes it for good from Trash.

From the board:

1. Open the board.
2. Open Board actions (the ⋯ button in the board header) and click Archive board.
3. Confirm the browser prompt.

From the sidebar:

1. Right-click the board's row under Boards, or click its ⋯ button.
2. Click Archive board and confirm.

Archiving takes the board away from everybody in the workspace, not just you. Laver moves you to the next board in the sidebar.

If the board you archive is the live board of a sprint series, that series is switched off and stops rolling over. Earlier sprint boards are untouched.

Restore an archived board#

1. Click Trash in the sidebar, below your boards.
2. Open the Archived boards tab, at the end of the row of tabs.
3. Click Restore on the board you want back.

The board returns to the sidebar in the position it had, with its name, its columns and all of its tickets. Anyone who had access to it before has access to it again.

Archived boards have a tab of their own, separate from the rest of the trash, because they are not on the 30-day sweep: nothing ever destroys one on a timer. You see the same archived boards you would have been able to open before they were archived.

Restoring a sprint board does not switch its series back on. The board and its tickets come back, but rollovers stay stopped; starting sprints again means starting a new series. See Sprints.

Delete an archived board permanently#

Archiving is the reversible half. When you are certain a board is finished with, a workspace owner or admin can take it away for good:

1. Archive the board, if it is not archived already.
2. Click Trash in the sidebar and open the Archived boards tab.
3. Click Delete permanently on the board's row and confirm.

This destroys the board, its tickets, their comments and every attachment on them, including the stored files. There is no undo and nothing is kept for 30 days — the countdown in the rest of Trash does not apply here. If the board was the source board of a sprint project, the project is deleted with it; the boards its earlier sprints produced are kept and become ordinary boards.

Members and guests do not see the button. They can still archive a board and restore one, because both of those can be undone.

Move around a wide board#

A board with more columns than fit on screen can be scrolled in three ways:

• Drag the board itself. Press any empty part of the board — the gap between columns, the space under a column's tickets — and push it left or right. The cursor becomes a closed hand while you drag. Cards, buttons and text fields keep their own behaviour, so dragging a card still moves the card.
• Scroll sideways with a horizontal wheel or a two-finger trackpad swipe.
• Swipe on a phone or tablet, where the board snaps to one column at a time.

Laver remembers where a board was scrolled to for the rest of the browser session, so a refresh comes back to the same columns rather than the start.

Configure status columns#

Columns are the vertical lanes on the board. Changing them affects everyone looking at the board.

Add a column#

1. Scroll to the right-hand end of the board to the Add column panel.
2. Click Add column, type a name (up to 100 characters), and submit.

The new column is appended after the existing ones. Escape cancels.

Rename a column, or give it a colour#

1. Click the ⋯ button in the column header and choose Rename column.
2. Edit the name and press Enter, or click the tick.

The row that opens also holds a colour swatch. Whatever you pick is the dot in the column header and the corner wedge on every card in it, so a board can be read by colour from across the room. Columns nobody has coloured keep the colours Laver assigns by position — the first two in the brand colours, the rest grey.

Renaming is safe: tickets stay where they are, and a renamed completion column stays the completion column.

Reorder columns#

• With a mouse: drag the grip handle in the column header left or right.
• With a keyboard: focus the grip handle and press Arrow Left or Arrow Right.

As with boards, a partial or stale list is refused with "The column list changed. Refresh and try again."

Delete a column#

Delete column at the bottom of the ⋯ menu, then confirm. Two rules stand in the way, and both say so rather than failing quietly:

• A board must keep at least one column, so the last one cannot go.
• A column that still holds tickets cannot go until they are moved. The refusal names the column and counts them: "Review still holds 4 tickets. Move them to another column first."

Move the tickets out — drag them one at a time, or use Select all in the same menu and then Set status in the group actions bar — and the column deletes.

The completion column#

Exactly one column per board is marked as the completion column, and the header shows a tick beside its name. Laver sets it when the board is created — the last of the three default columns, Done — and you can move it:

• Set as completing column in another column's ⋯ menu hands it over. The column that had the mark loses it in the same write, so a board never has two.
• On the column that holds it the same row reads Not the completing column, which takes the mark off and leaves the board with none. Nothing breaks: the hover tick shortcut and sprint rollovers simply have no column to treat as finished until you give it to one.

Columns you add yourself are never created as the completion column.

The merged pull requests column#

One column per board can be the one merged pull requests land in, and it shows a merge badge beside its name. No board has one until you give it away:

• Set as merged pull requests column in a column's ⋯ menu hands it over, and takes it off whichever column held it before — a board never has two.
• On the column that holds it the row reads Not the merged pull requests column, which leaves the board with none. Merges are still recorded on the tickets they belong to; nothing moves by itself until a column is tagged again.

Laver does not watch your repository, so something has to say the merge happened: a GitHub Actions job, one call, and the ticket moves. The whole of it — the workflow, the call and what comes back — is in Tickets by API. A ticket that arrives this way moves exactly as if somebody had dragged it: the column's entry requirements still apply, and a ticket they refuse stays where it is.

Entry requirements on a column#

A column can be given conditions a ticket has to meet before it is allowed in — "nothing reaches Ready for review without an attachment and no unfinished blockers". Set them from Entry requirements in the column's ⋯ menu.

The dialog offers six conditions about the ticket itself:

The two subtask conditions read as the same demand and are not: Every subtask ticked off is about unfinished work and a ticket with no subtasks passes it, while At least one subtask is about the checklist existing at all. A column that wants "nothing enters without acceptance criteria" wants the second one.

Underneath, each of the board's custom fields can be required too: a checkbox field has to be ticked, and every other type has to be not empty. Tick what the column needs and press Save; the whole set is saved at once, and up to 20 conditions can be put on one column.

A column with requirements says so under its header — "Needs at least one attachment, no unfinished blockers" — so the condition is visible before anyone drags a card at it. A move that does not meet it is refused with a sentence naming every unmet requirement, not the first one.

Three things are worth knowing before you turn one on:

• The check runs on the way in, not on what is already there. Adding a requirement today leaves the tickets already in that column exactly where they are, and a ticket already in the column can be edited freely.
• Filling the gap in the same request counts. A single update that adds the due date and moves the ticket is accepted; you do not have to save twice.
• Only some paths are gated. Dragging a card, the Status dropdown, a hover shortcut and the API all go through the check. Copying a board, importing tickets, a sprint rollover and restoring from Trash do not — those are moves you did not make one ticket at a time.

Setting the requirements is a workspace owner or admin job. Anyone who can see the board can read them, so a member always knows what a column wants even though they cannot change it.

Show two boards side by side#

With more than one board in the workspace, Split view in the board header opens a second board in a pane beside the current one. To choose which board that is, open the ⋯ menu on any board in the sidebar and pick Open in split view; the pane bar names the board it is showing. You can also move around inside the pane itself, the same way you would on a full board.

The two panes are independent — you can read and edit in both — and a ticket can be dragged from either one to the other. Pick up a card and drop it anywhere on the board opposite; it lands in the column of the same name there, or in that board's first column when nothing matches, which is what the Move to board menu does too. Dragging one card of a selection takes the whole selection with it. Close the pane with the cross on the pane bar or by pressing Split view again.

Everything else the board can do#

The ⋯ menu in the board header holds the rest of the board. None of it changes how the wall itself works, and nothing here is switched on for you:

Stats#

Two halves, one page. The top is what is on the board right now: how many tickets it holds, how many are completed, how many are still open, the share that is completed, then a breakdown by stage, a breakdown by label, and how many tickets arrived in each of the last twelve weeks.

Under How work has been moving is the second half, measured from the column history of the last twelve weeks. A ticket counts as delivered when it reaches the completion column — a board that has not marked one has nothing here to measure.

All of it is measured from what actually happened to the tickets. Nobody estimates anything, so there are no points, no velocity and no burndown — a cycle time you did not have to fill in a form to get is the trade.

Archived tickets are left out throughout. Anyone who can open the board can open its stats.

Timeline#

A ticket with a start date, a due date or both is drawn as a bar against a calendar; drag the bar to move it, or either end to change how long it runs, and the dates are saved on the ticket. Tickets with no dates cannot be drawn, so the page lists them underneath with the reason rather than leaving them out quietly — on most boards that is the longer list.

It is a second way to look at the same tickets, not a second place to keep them. The board stays the default.

Activity#

Every time a ticket moves between columns on this board, in one list with the most recent at the top: who moved it, from where to where, and when. It reads the same history the ticket dialog shows one ticket at a time. Archived tickets are left out, and you can narrow the list to one person or one column.

Feedback forms#

A form is a public link you can send to anyone — a beta tester with no Laver account included. What they write arrives as a ticket on this board.

1. Open ⋯ → Forms in the board header.
2. Give the form a heading, and an intro if the heading is not enough.
3. Choose which column responses land in. The default is the first column.
4. Optionally choose a number custom field to write the 1–5 rating into.
5. Create form, then copy the link.

Whoever fills it in sees your heading and intro, a message box, and optional name, email and 1–5 rating. They never see the board.

• Only the workspace owner can create, change or see the link for a form. Everyone else on the board sees which forms exist and how many responses each has taken.
• The link is the only credential. Treat it like a password; Switch off stops it working immediately, and a form can be switched back on later.
• A form takes up to 500 responses, and a board can have up to 20 forms. The count is shown beside each form, next to how many of those responses are still live tickets.
• The rating always goes into the ticket description. Choosing a number field as well puts it on the card and gives it a column of its own in a CSV export, which is what makes the answers countable.

Forms are on the free plan as well as the paid one.

If something is refused#

Board writes can fail for reasons that have nothing to do with the board — an unpaid invoice makes a workspace read-only, and a workspace with no subscription is closed to everyone until one is started. The message says which. See Errors.