Building Blocks
Workflows
The lifecycle of a ticket, configuration item or task — a sequence of statuses plus the rules for who can move from which status to which.
Updated Jan 23, 2026
Configuration · Building Blocks · 3.6
A workflow is a set of statuses + the transitions between them + who can perform which transition. Every ticket, every configuration item, every task is attached to a type, and the workflow hangs off that type. Well-designed workflows = a clear process flow; poorly designed = “so what’s the status of this ticket actually?”.
Why this matters to the business
"Nobody knows when something is done"
Status names the business understands — not "Status 3" or "Pending review".
"Everyone closes every ticket"
Transitions are role-specific — only managers can close, handlers can resolve.
"Approval lives in an Excel"
Approval status inside the workflow itself — including who can approve and what comes next.
"Different flow per type"
An incident has different steps from an access request — each gets its own workflow.
The mechanism
Type
Ticket type, CI type or task type. Decides which workflow applies to a record.
Statuses
The phases a record moves through. A new type ships with four default statuses (see below).
Transitions
Allowed moves between statuses, plus which authorisation groups are allowed to perform them.
The four default statuses
For every new ticket, CI or task type Gfacility creates four statuses automatically:
| Status type | Role |
|---|---|
| Default status | Starting point. Every new record lands here automatically. |
| Approval status | Waiting on approval. Optional but useful for change/finance flows. |
| Cancellation status | Withdrawn by the requester — not the same as rejected. |
| Rejection status | Refused by handler/approver. Final status. |
On top of these four you can add your own statuses freely (In progress, Scheduled, Blocked, Waiting on customer, Resolved, Verified, …). Each status gets its own text colour and background colour for visual recognition.
Which decisions will you make?
How many statuses per type?
5–7 is recommended. More = confusion; fewer = too coarse for reporting.
Which transitions are allowed?
Blocked → Resolved is open to everyone, but Verified → Reopened only the reporter.
Which group can perform which transition?
Falls straight out of your RACI: whoever is the "A" for a step can perform the transition to the next status.
One workflow or per type?
If processes differ materially → separate workflow. Otherwise one workflow with variants via custom fields.