Pipelines
A pipeline is the set of stages a work item moves through, plus the rules about moving between them. It is what the columns on the work board are, and what a refused move is refused by.
Where to find it
| Screen | Where it lives | What you need |
|---|---|---|
Pipelines — /admin/pipelines | Settings → Work & scheduling → Pipelines | Permission to view the work setup; changing a pipeline needs the pipeline designer permission |
Reading work items is not enough to open this page: a person who may only read work items is told You do not have permission to view pipelines. The keys are listed in Who can do this at the end of this page.
The catalogue
Each row shows the pipeline's Name (with its slug, and a disabled tag when it is switched off), its Stages in order — a done stage in bold, a limit as (≤5) after a stage's name — its Type affinity, how many Gated moves it declares (the rows under Allowed moves and gates below), how many items are In flight on it, and its Origin.
Origin is global (shared by every space, read-only here) or this space. A global row you want to change is copied first — Copy to this space — and your copy then shadows the shared one. A global row that has been shadowed says so: global · shadowed, and it offers only View. + New pipeline starts one from scratch.
Stages
A pipeline is a list of stages, each with a Slug (its identity), a Name, a Done (terminal) tick and an optional WIP limit. The arrows ↑ and ↓ put the stages in order, + Add stage adds one, and the In flight column shows how many items sit in each stage now. The pipeline's own Slug (identity) is fixed once it is saved.
A WIP limit caps how many items may sit in that stage at once: a move into a full stage is refused. Stages with no limit read unlimited.
A stage that still holds items cannot be removed. Saving refuses and says how many items would be stranded in which stage — move them to another stage first, or keep the stage.
Allowed moves and gates
This is the part worth reading twice, because the default is permissive and the rule is per destination:
No rows = free movement. A row targeting a stage restricts entry into that stage to the listed moves.
So adding one row does not lock the whole pipeline down — it locks down entry into the one stage that row names. Stages nobody has written a row about stay freely reachable. + Add move adds a row and Remove move takes one away.
Each move row has:
| Field | What it means |
|---|---|
| From | the stage being left — or any stage, which states a rule once for every entry into the destination |
| To | the stage being entered |
| Required permission key | who may make this move |
| Gate | a condition the move must pass; + Add gate adds one |
| Config (JSON) | the gate's settings; choosing a gate fills in an example |
| Message key (optional) | an optional custom wording for the refusal |
The Gate list names each gate by its short name:
| Gate | The move passes when… |
|---|---|
| checklist_complete | every line of the item's checklist is ticked |
| required_fields_filled | the fields named in its settings are filled in (custom fields too) |
| flag_present | the item carries the named flag in a status lane |
| flag_absent | the item does not carry it |
| children_terminal | every child item has reached a done stage |
| rollup_threshold | a rollup or calculated field on the item meets the number in its settings |
| filter_match | the item matches a filter, written in the same AND/OR terms views use |
A move is checked in a fixed order: is the move allowed, does the person hold its permission, do all its gates hold, is there room under the WIP limit. A refusal names the unmet rule in plain words — not "move refused", but which condition was not met.
Every gate in today's list can be checked. A gate whose check has not been built would carry a ⚠ in the list and say so: Not evaluable yet — moves into this stage will be refused until its evaluator lands. Saving such a pipeline would show the same warning. That is deliberate honesty — a gate that cannot be checked refuses rather than silently passing.
The override key
Override permission key (who may bypass the rules — audited) names who may bypass the move rules, the gates and the WIP limit. A new pipeline starts with the space's standard override permission filled in. A bypass is never automatic: it has to be asked for on that one move, and every bypass is audited. No screen in the CRM offers the bypass yet, so for now nobody can use it from the screens. It exists because real work sometimes has to move anyway; recording who did it is what makes that acceptable.
Type affinity
Type affinity ties a pipeline to a work item type, or leaves it at any. A work item type then names its default pipeline — see Work Items. If you tie a pipeline to a global type that this space has its own copy of, saving warns you to tie it to the copy instead: items made with the copy would not accept the pipeline.
Enabling and disabling
Enabled controls whether the pipeline can be used. A disabled pipeline keeps its stages and its history, and it disappears from the board and from the intake pickers. A pipeline that still has items on it cannot be disabled: saving refuses, says how many items ride it, and asks you to finish or delete them first, or keep the pipeline enabled.
Who can do this
| To… | You need |
|---|---|
| open Pipelines and see every pipeline | crm.work_items.setup.view |
| create, change or copy a pipeline | crm.work_items.pipelines.manage |
| move items past the rules (the usual override) | crm.work_items.move_override, or the key the pipeline names |