--- title: Statuses and workflow description: What status columns are, how they are configured per board, what marking one as complete means, and how a ticket moves between them. section: Concepts order: 2 --- # 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.** The pencil beside the column name. - **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. Two things you cannot do, so that you do not go looking for them: - **You cannot delete a column.** Nothing in the app removes one. Reorder an unwanted column to the end and stop using it. - **You cannot choose a column's colour.** Laver assigns the colours in the board header; there is no colour picker. 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](/docs/boards-and-tickets/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. Two limits worth knowing. Columns you add yourself are never marked complete — new columns are created unflagged — and there is no setting anywhere that moves the flag to a different column. On a board created by Laver it stays on the column that started as _Done_, even if you rename that column or drag it elsewhere. If your workflow ends somewhere else, rename the original column rather than adding a new one after it. ## 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. ## 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](/docs/agents-and-api/tickets-by-api).