Workflows & 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
• Description: a status can carry an optional description saying when work moves into it and what the exit condition is. It is read from the status picker, from an info icon in the column header and from the task’s status badge, and it carries over when a board is copied. What similarly named statuses (Review / Test / QA) are actually for stops being tribal knowledge
• 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). While the limit is reached, no task can be moved into that status or created there
• Auto-assignment: a task can be assigned automatically when it moves into a status or is created directly in it (unless an assignee was picked)
• Edit lock: a status can be marked "Editing is locked for tasks in this status". Only roles carrying the "Edit tasks in a locked status" permission can change the fields of tasks sitting there; moving between statuses is unaffected, so work keeps flowing while an approved record can no longer be altered after the fact

Transition rules

Under Board Settings > Transitions you define which status may move to which. The "Only allow the transitions defined below" switch is off by default: while it is off, an undefined move (straight from the first status to the last, say) is allowed; once on, only defined transitions are accepted and anything else is refused with a notice saying so. Each defined transition can additionally carry three kinds of requirement:

The transition list is in automatic order by default: by source status, then by target status. You can order the rows by hand by dragging them; in a manually ordered list new transitions are added at the end, and the "Reset to automatic order" button puts the list back into automatic order. Reordering requires the "Edit status transitions" permission.

Auto-assignment on entering a status

Write a rule on a status and the task is assigned automatically every time it enters that status. A rule takes one of three shapes: assign to the reporter, assign to whoever is named in a person-type custom field on the task ("work moved to In review goes to that task’s reviewer"), or assign to a board member you pick directly (for a review step that must always land on the same person). 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. The rule also fires when a task is created directly in that status, unless an assignee was picked on the creation screen, in which case that choice stands. If the assignment cannot be made on a move (the field the rule reads is empty, say) the reason is written to the audit log.

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.

Labels

Every board has its own label list, managed under Board Settings > Labels; each label has a name and a colour. A new board starts with bug, feature, chore, design, docs and tech-debt. Changing the list requires the "Manage labels" permission, and putting a label on a task requires "Edit system fields". A deleted label is also removed from the tasks carrying it.

Custom field types

There are ten field types. Fields are defined per board, reordered by dragging (a new field goes to the end of the list without disturbing the existing order), and can be used on the task form, as list columns, in filters, in exports and on dashboard cards.

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
• Exceptions: a placeholder exists only on text, number, link and email fields; a default value can be given only on text, number, person (single-person fields only), checkbox, link and email fields; select, multi-select, date and formula have none. A formula field cannot be made required, since nobody fills it in

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
• The difference between two date fields is computed in days. The "Calculate as business days" option excludes weekends, the public holidays defined in the board work calendar and half days; both ends are counted (Monday to Friday = 5 work days, the same rule as Excel NETWORKDAYS)
• The "Calculate as business hours" option gives the same gap in hours: working hours, the lunch break and holidays come from the board work calendar, and partial days outside working hours are prorated. The two options are mutually exclusive; turning one on turns the other off
• If a date field also keeps the time of day (a half-day leave, say) the result comes out with decimals: the total working time is divided by the daily capacity
• A date difference is computed only when the formula’s first term is the gap between two date fields; the work-hours option needs both fields to keep the time of day. A formula takes at most 10 terms

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.

On top of that you can add a STATUS CONDITION: the section is editable only while the task sits in one of the statuses you pick (several can be chosen). It is added to the rule rather than replacing it, so it reads as "the assignee AND while the task is In review or Test". 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
• The GitLab Project field, while the board is connected to GitLab, appears in the Custom fields list like any other field: it can be placed in a section and then follows its rule. Its options come from the integration, so it cannot be deleted or edited by hand. Priority and Story Point stay fixed fields and cannot be placed in a section
• The status condition is read correctly while creating a task as well: since the status the new task will be born in is known, a section editable in that status does not appear locked on the creation screen

Which sections appear on the task screen

The task screen has a settings tab of its own: Board Settings > Task Screen. The built-in sections are managed there (Custom fields, Attachments, Links, Subtasks, Diagrams and GitLab activity): "Show" and "Start collapsed" are chosen separately for each, and the order the boxes appear in is set by dragging. 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.

The Fixed fields section of the same tab switches the built-in fields on and off: Sprint, start date, due date, class of service, Fix Version, Affects Version, Watchers, Labels, Issue type, plus Priority and Story Point. These used to be present on every board; switching off the ones you do not use simplifies the task screen. Since Kanban boards have no sprint concept, the Sprint field and its setting never appear there.

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.

• Templates are defined under Board Settings > Templates. Creating, changing and deleting them requires the "Board configuration: fields, issue types, versions, templates, calendar" permission; using one on a new task only needs the right to create tasks
• When you set up a new board from an existing one, templates come along by default (as a checkbox)

When a new task is created

Which status a new task is born in is chosen in the workflow settings: you tick the permitted start statuses and mark one as the default. The creation screen lists only the permitted ones; with none selected, behaviour stays as it is and the task starts in the first status of the flow. A team can then write the rule "every piece of work starts in Triage" into the screen itself.

With the "Description must match a task template" switch under Board Settings > General turned on, a new task must pick a template and the template’s required sections cannot be left empty. Required sections are marked on the template’s own headings. The check is structural: carrying the heading in prose or pasting it empty is not enough, the body under the section has to be filled, and missing sections are reported one by one. The switch is off by default and existing tasks are unaffected; the check only runs while the description is being changed.

The quick-add box under a column is a board setting too, and it is off by default. You switch it on under Board Settings > General; on boards with required fields or a GitLab project choice the box opens the full creation screen rather than producing a half-filled task.

A template for the task title

A template for the task title can be defined in Board Settings > General. If the title is left empty on save, it is computed from the template: {reporter} for the creator, {assignee} for the first assignee, {cf:key} for the value of a custom field (use the field’s key, not its name; person-type fields give the person’s name). On a time-off board, "Time off - {reporter}" fills in the title of every new task by itself; write a title yourself and the template stays out of the way.