Workflow states

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: the workspace owner or an admin can create new states and rename existing ones, these included. What you can’t do is delete these six, reorder the states 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. They’re managed by the workspace owner and the admins; other members don’t see this section. They 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.
• Delete a state they added by hand, as long as nothing uses it: no issue in any project, no automation and no SLA rule. If something does, the app tells you what.

All of this is shared configuration: changing it changes it for the whole team.

What you can’t do

• Delete the six states the team started with, or an added state that’s in use.
• 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, and the state agents close a task in (see the next section) is stored by its id, so the new name doesn’t break it.

When a task is finished

Below the list of states there’s the option «When a task is finished, the agent leaves it in: [selector]». It decides which state an agent leaves an issue in once it considers its work done: whether it goes through a review or is closed straight away.

The selector offers, under their current names:

• The review states: «In Review» and any started states you’ve created after «In Progress».
• The completed states: «Done» and any completed states you’ve created.

«Backlog», «Todo», «In Progress» and «Canceled» are left out. The default is «In Review». Like the rest of the page, the workspace owner and the admins can change it.

The agent finds out through the MCP: claim_issue, get_issue and next_ready_issue return an agentCloseState field with the state’s id (stateId), its name (name) and a ready-made instruction (instruction). If the agent leaves the task in a different final state, change_issue_state tells it so in its next steps.

It’s an instruction, not a lock: an agent works with a person’s key, and that person can close a task by hand in whatever state they like.

Related: Issues · Cycles · Insights.