Statuses, priorities and ticket types
Three small vocabularies do most of the organising in KAMI Tasks. Getting them straight — especially the difference between a status and a column — prevents most of the confusion people have about why a board and a report disagree.
Where: columns are fixed; statuses are per project, under Settings › Project Manager You need: project admin rights to change a project's statuses
Columns versus statuses
KAMI Tasks has six system columns, identical in every project:
To Do · In Progress · Under Review · Done · On Hold · Blocked
These are what the Kanban board is built from and what reports aggregate by.
On top of that, each project defines its own custom statuses — its own labels for stages of work — and maps each to a system column. A development project might run Not Started → In Discussion → In Progress → QA Testing → Pending Deploy → Resolved → Closed; a simpler project may use the system columns as they are.
The consequence to understand: several statuses can share one column. QA Testing and Pending Deploy can both map to Under Review, so filtering a report by column returns all of their tickets together. The status is the precise state; the column is the family it belongs to.
That is why a board showing four cards in Under Review can correspond to a report row saying eight — the report is counting a column, the board is showing a filtered status.
On Hold and Blocked are not the same
- On Hold — deliberately paused. Nobody is waiting; you chose to set it aside.
- Blocked — cannot proceed. Something or someone is in the way, and it needs unblocking, not patience.
Blocked tickets surface on My Work and can trigger automations; On Hold ones chase nobody. Use the one you mean — a Blocked ticket that is really On Hold trains people to ignore the Blocked signal.
Ticket types
| Type | Use it for |
|---|---|
| Epic | A large initiative other tickets belong to |
| Story | A user-facing piece of work |
| Task | Concrete work that is not user-facing |
| Bug | Something broken |
| Improvement | Making something existing better |
| Subtask | A child step of another ticket |
Priorities
Trivial → Minor → Major → Critical → Blocker, in rising urgency.
Two of these do extra work: Critical tickets with no assignee can trigger an automation, and Blocker means the sprint does not ship with this open.
Keep the scale honest. If everything is Critical, nothing is, and the automations built on it become noise.
What Happens Next
- Changing a status moves the ticket on the board, because the board is built from the column that status maps to.
- Reports, insights and automations read columns and statuses, so a mapping change alters what they report from that point.
- Adding a status to a project makes it available immediately; existing tickets keep the status they had.
Tips
- Map statuses to columns deliberately. The mapping decides what every report says. A status mapped to the wrong column quietly misstates progress for everyone reading the numbers.
- Fewer statuses than you think. Each one is a decision someone has to make correctly every time. If two statuses never change what anyone does, they are one status.
- Agree what Blocked means before relying on it. "Waiting on someone else" and "cannot start" are different, and teams that do not agree end up with a Blocked column that means nothing.
- Review the priority distribution occasionally. A backlog that is 60% Critical is telling you the scale has collapsed.