Workflow states
The states an issue moves through: six per team to start with, extensible, classified by category.
A workflow state is each situation an issue moves through («Backlog», «In Progress», «Done»…). Every team has its own set of states, and they all start with the same six.
The six states
When you create a workspace, each team is set up with these states. In brackets, the category each one belongs to:
| State | Category | What it means |
|---|---|---|
| Backlog | backlog | Pending, unprioritized. |
| Todo | unstarted | Prioritized, not started yet. |
| In Progress | started | Under way. |
| In Review | started | Work finished, waiting for review. Still counts as work in progress until it’s approved. |
| Done | completed | Finished. |
| Canceled | canceled | Dropped. |
Every team starts with these six, but they’re not a closed list: an admin can create new states and rename existing ones, these included. What you can’t do is delete them, reorder them or change their category; the details are in How to use it.
Why the category matters
A state’s name is a label; what drives the application’s logic is its category. That’s what makes «In Review» count as work in progress without anything having to know that particular name:
- Board and list: issues are grouped by state, and the visual indicator comes from the category.
- Metrics: velocity and burndown sum issues in the completed category; Insights measure work in progress (started) and completed work.
- Timestamps: when an issue moves to a started, completed or canceled state, the app automatically records when it happened.
One detail worth knowing about those timestamps: when you reopen an issue (move it back to an in-progress state), the completed and canceled marks are cleared but the date it started is kept. That way the cycle time in Insights still measures from when the work actually began, not from the reopening. Completed and canceled are also mutually exclusive: an issue can’t be done and canceled at the same time.
How to use it
In Settings → States you see the states grouped by team and ordered by category. The team sees them read-only; an admin can:
- Create a new state, choosing name, category and color. The name has to be unique within the team, and the new state goes last in its category.
- Rename any of them, including the six the team started with.
- Change the color.
All of this is shared configuration: changing it changes it for the whole team.
What you can’t do
- Delete a state.
- Reorder the states: their position is set when they’re created.
- Change the category of an existing state. The category is chosen when you create it and is the only irreversible decision in the form, because it’s what decides how that state counts in the metrics (see Why the category matters): changing it would rewrite history, and issues closed months ago would start counting as work in progress.
The triage category isn’t offered when creating a state.
Renaming, on the other hand, is safe: the logic goes by category, not by name. With one practical caveat: agents use «In Review» as a review step by convention, so if you rename that state the app warns you that you may confuse them.