For AI agents: a documentation index is available at /llms.txt. A markdown version of this page is available at /guide/cloud/tasks/custom-fields-and-statuses.md.
Custom fields and statuses
Shape tasks and workflow to how your team actually works — without creating a form nobody fills in.
Pro and Premium
Custom fields and custom task statuses require Pro Unlimited or above. See the feature matrix.
#Custom statuses
The default statuses are a starting point. Custom statuses let the board reflect the stages work genuinely passes through.
#Designing them
Describe the real path
Ask the team to walk a recent task from idea to shipped. The stages they name are your statuses — not the ones you wish they used.
Keep it to five or six
A board with six columns is readable. Twelve means horizontal scrolling and a board people stop opening.
Separate waiting from working
"In review" and "Waiting on customer" are different problems. If work regularly stalls in a state, give it a column — that is where your queue is.
Define done explicitly
Write down what "Done" requires. See checklists.
Renaming a status changes its meaning retroactively
Historical tasks move with it, so past reports shift too. Get the set right before there is much data.
#A workable default
| Status | Means |
|---|---|
| Backlog | Not started, not committed |
| To do | Committed to this sprint or week |
| In progress | Actively being worked |
| In review | Waiting on someone else |
| Done | Meets the definition of done |
#Custom fields
Fields specific to your work — client, environment, release version, component, severity.
#Add them sparingly
Every field is a tax paid on every task created. Half-filled fields are worse than no field, because reports built on them are quietly wrong.
Tip
Before adding a field, name the decision it informs and the report it feeds. If you cannot, do not add it.
#Field types
| Type | Good for |
|---|---|
| Text | Free-form references — a ticket id |
| Number | Quantities, scores |
| Date | Dates other than start and due |
| Dropdown | A fixed set — environment, severity |
| Multi-select | Several from a set — affected components |
| User | A second person — reviewer, approver |
| Checkbox | A yes/no flag |
Prefer dropdowns over text
A text field becomes "prod", "Prod", "production" and "PROD" within a month, and cannot be reported on. A dropdown stays clean.
#Fields versus labels
Structured, one value, reportable. "Environment: staging".
Ad hoc, many per task, no structure. "needs-design", "blocked".
Use a field when you will filter or report on it. Use a label when you just need to mark something.
#Scope
Both can be defined per project, so a client-services project can carry a "Client" field that an internal project does not.
Per-project fields make cross-project reporting harder
If you want a workspace-wide report on a value, define the field consistently everywhere — or it will only cover some projects.
#Automation
Once statuses are meaningful, automation can act on them — assign a reviewer when a task hits Review, or flag anything sitting in Blocked for over two days.
Start with one rule that removes real manual work.
📥Next: import and exportGetting data in and out.