Laver docs
Open Laver
Concepts

Statuses and workflow#

A board's status columns are its workflow. There is no separate workflow setting, no transition rules, and no states hidden behind the board: the columns you see across the top are the whole model.

Columns belong to one board#

Status columns are per-board. Every board is created with the same three — Backlog, In progress, Done — and from that moment they are that board's own. Renaming In progress to Building on one board does not touch any other board, and two boards in the same workspace can have entirely different workflows.

A ticket sits in exactly one column of the board it is on, or in no column at all. A ticket with no column is legal in the data but has nowhere to render, so in practice everything you create through the app gets a column.

Configuring the columns#

All of this needs the owner, admin, or member role, on a board you can reach. Viewers see the columns and change nothing.

  • Add a column. Add column at the right-hand end of the board, then a name of up to 100 characters. It is appended after the existing columns.
  • Rename a column. Rename column in the column's ⋯ menu. The same row carries a colour swatch, so a column can be given a colour of its own. A column that has never been given one is drawn in the colour Laver assigns by position.
  • Reorder columns. Drag the grip in the column header, or focus it and use the arrow keys. The order you set is the order everyone sees.
  • Delete a column. Delete column in the same menu. Two rules protect you: a board must keep at least one column, and a column holding tickets cannot go until they are moved. Both refusals name the reason.
  • Choose which column means done. Set as completing column in the same menu — see below.
  • Gate a column. Entry requirements decides what a ticket must carry before it is allowed in — see below.

Give each column on a board a distinct name. Nothing enforces uniqueness, and duplicate names make the by-name lookup described below ambiguous.

What "complete" means#

Exactly one column per board is flagged as the completion column. On a new board that is Done, because the flag is set on the last of the three starting columns.

The flag does two things:

  • The tick shortcut. Hovering a card shows a shortcut button; with no shortcuts configured it is a single tick labelled Mark as completed, and it sends the ticket to the completion column in one click, from anywhere on the board.
  • Sprint carry-over. When a sprint rolls over, tickets in the completion column stay behind on the finished board and everything else moves to the new one. That is the whole definition of "unfinished" — see Sprints.

It is not a lock or a sign-off. A ticket in the completion column can be edited, moved back, or reopened like any other, and nothing is archived automatically.

Columns you add yourself are never marked complete — new columns are created unflagged — but the flag can be moved. Set as completing column in a column's ⋯ menu hands it to that column, and the column that had it loses it in the same write: a board has exactly one, never two. The menu on the column that holds it reads Not the completing column instead, which takes the flag off and leaves the board with none until you give it to somebody.

Moving a ticket#

Moving a ticket between columns is changing its status; there is no separate state to update. In the app, three gestures do the same thing:

  • Drag the card into another column, dropping it where you want it in the order.
  • Open the ticket and pick from the Status dropdown.
  • Use a hover shortcut on the card. You can configure up to four of these under Card display in the board header — each becomes a one-click move to that column.

Whichever you use, the move is saved immediately and pushed to everyone else with that board open, so a colleague sees the card move without refreshing. Two people dragging the same ticket at once is resolved by the ticket's version: one write wins and the other is told the ticket changed underneath it.

Moving a ticket to a different board is a different action — Move to board on the card's right-click menu — and it lands the ticket in a column on the destination board.

Entry requirements#

A column can be given conditions a ticket has to meet before it is let in — "nothing reaches Ready for review without an attachment and no unfinished blockers". The column header says what it wants, so the condition is visible before anyone drags a card at it, and a move that does not meet it is refused with a sentence naming every unmet requirement.

The gate is on the transition, not on the column's contents: adding a requirement today leaves everything already sitting in that column exactly where it is. Setting the requirements is an owner or admin job; anyone who can see the board can read them.

The full list of conditions, where the dialog lives, and which paths are not gated are in Boards.

Column names in the API#

Anywhere the API takes a status_uuid, it also takes a column name as status. This is deliberate: "the To Do column" is what a script actually has, and matching is case-insensitive and ignores surrounding whitespace, so "to do" finds To Do.

bash
curl -X POST https://api.laver.app/tasks/11111111-2222-4333-8444-555555555555/move \
  -H "Authorization: Bearer laver_..." \
  -H "Content-Type: application/json" \
  -d '{"version": 7, "status": "In progress"}'

Two rules apply:

  • Send status or status_uuid, never both — sending both is rejected with 400 "Give either status or status_uuid, not both."
  • The name must exist on that board, or you get 400 "No column named … on this board."

Names also work when creating a ticket and when filtering a board's tickets, so a script can post straight into a named column without reading the board first. The version field, the conflict response, and the full request shapes are in Tickets by API.