Workflows & custom fields
Statuses, transition rules, WIP limits, issue types and custom fields.
Each board has its own workflow. You can add and reorder statuses, define which status can move to which via transition rules, and set WIP limits on statuses.
Statuses
- Reorder statuses by dragging; give each a color
- Every status belongs to a category: To do, In progress, Done. Reports follow the category, not the name - name a status "Released" and put it in Done, and burndown and velocity count it as finished work
- WIP limits: cap how many tasks a status can hold at once (between 1 and 99). The column header warns when the limit is exceeded
- Auto-assignment: a task can be assigned automatically when it lands in a status
Transition rules
In the transition matrix you mark which status can move to which. An unmarked move is refused and the person trying it gets a notice saying so. Each transition can additionally carry two kinds of requirement:
| Requirement | How it works |
|---|---|
| Role requirement | Only people holding a given role can make the move. |
| Person requirement | The people you pick can move it even without the role. The two work as OR: whoever has the role, or is on the list, may move it; both are never required. A narrow rule for one person no longer means defining a role for them. |
Auto-assignment on entering a status
Write a rule on a status and the task is assigned automatically every time it enters that status. The rule looks at the task’s own data rather than a fixed person: assign to the reporter, or to whoever is named in a person-type custom field on the task ("work moved to In review goes to that task’s reviewer"). The assignment REPLACES the current assignees, because what it means here is a handover: when work drops into testing it goes to whoever owns testing.
Issue types
Four built-in types come preset: Epic, Story, Task, Bug. You can set an icon and color per type and add new types. The type separates tasks visually and is used for filtering/grouping. Epics are parent items that group child work.
Custom field types
There are ten field types. Fields are defined per board, reordered by dragging, and can be used on the task form, as list columns, in filters, in exports and on dashboard cards.
| Type | What for | Its own settings |
|---|---|---|
| Text | Free writing: a note, a rationale, an external reference. | Single line or multi-line. |
| Number | Measured values: effort, cost, quantity. | Minimum and maximum, integers only, a unit ("days", "$"). |
| Select | One value from a fixed list. | Up to 50 options, each can carry a colour. |
| Multi-select | Several values from the same list. | Up to 50 options, colour coded. |
| Date | Anything tied to a calendar: requested on, planned release. | Whether to keep the time of day; "treat as a deadline". |
| Person | Roles that need a name on the task: Reviewer, Requester, Approver. | Whether several people can be picked; "the person here watches the task". |
| Checkbox | A yes/no fact: "customer was informed". | Whether it arrives ticked on a new task. |
| Link | The address of a record in another system. | Once filled, clicking the box edits it and clicking the link text opens the address. |
| An address belonging to someone (who may not be a product user). | Behaves like the link field. | |
| Formula | Its value is CALCULATED from other fields, never typed in. | See the section below. |
Settings every field shares
- Required: the field cannot be left empty. It is marked with an asterisk, so you do not discover it only when saving
- Default value: the field arrives filled on a new task. It does NOT touch existing tasks - changing a default later would mean rewriting history
- Placeholder: the grey hint in an empty box. It is not stored, it only shows what to write
- Description: a short instruction behind the (i) next to the field name. The name stays short and scannable, the instruction lives elsewhere
- Disabling: a field you do not use can be switched off. A disabled field is invisible in forms and lists and is not required, but its definition and every value entered stay in place
Built-in fields such as priority and estimate cannot be deleted: card badges, the capacity report, sprint metrics and filters assume they exist, and deleting one would silently empty those screens. For a team that does not use them the way out is disabling, not deleting.
The formula field
A formula field takes its value from other fields. The builder works line by line: you pick a first term (a field, a number or a fixed text), then add an operation and a term at a time. There are five operations: add, subtract, multiply, divide and join side by side.
- Evaluation runs LEFT TO RIGHT; there is no multiplication precedence. A hidden precedence rule would produce a field that answers differently from the order you see on screen
- The result can be a number or text; a number can carry decimal places and a unit appended at the end
- The calculated value is STORED. That is why filters, sorting, list columns, CSV/Excel export and dashboard cards need no extra setup
- It recalculates the moment a source field changes, even while you are creating the task
- Formulas can read each other; a definition that forms a loop is not saved
Field groups (form sections)
Custom fields can be split into sections on the task form (Board settings > Custom fields > Field groups). Instead of twenty fields flowing in one list you get collapsible headings. Fields without a group stay in a single list, so your existing boards are unaffected. Sections are reordered by dragging and each can start collapsed.
Each section carries a "who fills this in" rule. The rule sits on the section rather than on each field: three rules for three sections instead of twenty rules for twenty fields.
| Rule | Who can fill it in |
|---|---|
| Anyone | Everyone with write access on the board. The default; behaves as if there were no rule. |
| Specific roles | People in the roles you pick. Both built-in and custom roles can be chosen. |
| The person named in a field | Whoever is named in a person-type custom field on the task. The rule follows THAT TASK’s value rather than a role: "the reviewer of this task fills in the review section." |
| Assignee or reporter | The task’s built-in people. |
On top of that you can add a STATUS CONDITION: the section is editable only while the task sits in a given status. It is added to the rule rather than replacing it, so it reads as "the assignee AND while the task is In review". A section can therefore open exactly when it should be filled in and lock once the work moves on.
- The rule is enforced ON THE SERVER; the lock in the interface is not decoration. A request from someone without access is rejected, bulk import included
- The person who should fill in a section is shown in its heading, and can be assigned while the section is locked
- A board admin is NOT exempt from the rule. Exempting them would make it read as "closed to everyone except admins" and blur the question of who filled in a quality record. An admin can change the rule; that is the way to fill the field directly
- Deleting a section does not delete fields: they and every value entered stay in place, and the fields return to the ungrouped list
- A field is only required from the person who can actually fill it in, so a required field in a restricted section does not block anyone else from creating a task
Which sections appear on the task screen
Alongside custom fields you also manage the built-in sections of the task screen (Board settings > Custom fields > Task sections): Custom fields, Attachments, Links, Subtasks and Diagrams. "Show" and "Start collapsed" are chosen separately for each. These sections used to appear on every board with no way to switch them off, so a team that never draws diagrams still saw an empty "Diagrams" box on every task. It is a board setting, so everyone on the team sees the same screen, and it carries over when you copy a board.
Task templates
For recurring work you define task templates per board. A template carries the status, assignee, labels, issue type, description and custom field values. Pick one from the template selector on the new task screen and those fields arrive filled; you only write the title and adjust whatever needs adjusting.
- Creating a template is open to every board member; changing or deleting one belongs to its creator and to board admins
- Defining templates falls under the "Manage fields, issue types, versions and templates" permission
- When you set up a new board from an existing one, templates come along by default (as a checkbox)
Changes to workflow, issue-type and custom-field DEFINITIONS are written to the audit log. Changes to custom-field VALUES on tasks are recorded too: who changed "Approver" or "Risk class" and when does not stay only in that task’s own history, it can also be picked out from the event filter.