---
title: Stage-Gated Workflow
slug: stage-gated-workflow
kind: topology
summary: A record cannot advance to the next stage until stated conditions are met, and the interface says exactly which condition is blocking it.
problem: >-
  A process has rules — no job starts without insurance on file, no invoice
  sends without approval — and the rules live in people's heads. They are
  enforced by whoever notices, which means they are enforced inconsistently and
  discovered late.
family: [workflow, act]
data_shape: [record]
principles: [orientation, consistency, surface-dont-bury]
interaction: [decision]
density: low
complexity: high
status: stable
visibility: public
use_when:
  - Real conditions must hold before work proceeds, and the cost of proceeding wrongly is high.
  - The same conditions apply to every record, so they can be stated once.
  - People currently enforce the rules by memory and vigilance.
avoid_when:
  - The rules are advisory. A gate that gets overridden constantly is worse than a warning.
  - The conditions differ every time, so no gate can be stated.
  - Speed matters more than correctness here, and a blocked record costs more than a wrong one.
alternatives:
  - slug: checklist-workflow
    when: The items must be tracked but should not BLOCK anything.
  - slug: linear-workflow
    when: Stages are enough and the conditions are not worth enforcing in software.
ask_leo: |
  Add gates to this workflow.

  - State each gate as a named, checkable condition attached to a specific
    transition, not as a general rule. "Cannot move to Scheduled until the
    insurance certificate is on file."
  - Always show the gate BEFORE it blocks: on the record, list the conditions
    for the next stage and which are met. Nobody should learn about a gate by
    being refused.
  - When the advance action is unavailable, say precisely which condition is
    outstanding and link to the thing that would satisfy it. Never a disabled
    button with no explanation.
  - Provide an override for a named role where the business genuinely needs one.
    An override must require a reason, be recorded in the history, and be
    visible on the record afterwards.
  - Evaluate gates live, so satisfying a condition unblocks the record
    immediately without anyone re-checking.
  - Report on what is blocked and by which gate, across all records. The most
    valuable output of this pattern is learning which gate stalls everything.
related:
  - title: Checklist Workflow
    url: /patterns/checklist-workflow
    summary: The same conditions tracked without blocking — decide deliberately which you want.
  - title: Linear Workflow
    url: /patterns/linear-workflow
    summary: The stages the gates sit between.
---

## The shape

```
  New ──▶ Scheduled ──▶ In progress ──▶ Invoiced
           ▲
           └── GATE: to schedule this job
                 ✓ Client contract signed
                 ✓ Purchase order raised
                 ✗ Insurance certificate on file   ← blocking, and it says so
                     → Upload certificate

           [ Schedule job ]  unavailable: 1 condition outstanding
           [ Override (ops manager) ]  reason required, recorded
```

Four properties:

1. **The gate is visible before it blocks.** Conditions are listed on the record
   from the moment it enters the stage, so nobody is surprised.
2. **The block names the specific condition** and links to the fix.
3. **Overrides exist, are role-limited, require a reason, and are recorded.**
4. **Gates evaluate live**, so satisfying a condition unblocks immediately.

## Why it works

It moves a rule from memory into the system, which is the difference between a
policy that mostly happens and one that always does. The value is not
enforcement for its own sake — it is that the rule becomes **stated**, and a
stated rule can be argued with, measured and changed.

The reporting is the sleeper benefit. Once gates are explicit, "what is
blocked and by what" is a query. Most businesses discover that one gate accounts
for the majority of their stalled work, and that is usually actionable in a way
nobody could see before.

## The override is not a weakness

Teams often resist overrides because they seem to defeat the point. In practice
the opposite is true: **a gate with no override gets routed around**. People
will create a duplicate record, mis-set a field, or do the work outside the
system entirely — and then you have neither the rule nor the record.

A recorded override with a reason keeps the work inside the system and turns
exceptions into data. If one gate is overridden 40% of the time, it is the wrong
gate, and now you can prove it.

## Getting it wrong

- **A disabled button with no explanation.** The single most common failure —
  the person cannot proceed and cannot find out why.
- **Gates discovered on refusal**, rather than shown on arrival at the stage.
- **No override**, which pushes work out of the system.
- **An unrecorded override**, which is the same as no gate but with more
  ceremony.
- **Gates on advisory rules**, which trains everyone to override reflexively and
  devalues the real gates.
- **Stale evaluation**, where satisfying the condition does not unblock until
  someone reloads or a nightly job runs.

## Exemplars

**Deployment pipelines** are the clearest technical example: tests, review and
checks are conditions on a transition, the failing one is named, and a
break-glass override exists and is logged.

**Regulated onboarding** — banking, insurance, healthcare — is where the pattern
originates commercially, and where the reporting benefit is most visible: the
blocked-by breakdown is the operational dashboard.

**Procurement approvals** demonstrate the override design well: thresholds
determine who may override, and the reason field becomes the audit trail.

The extractable rule: **a gate must explain itself before it refuses.** A rule
the software knows and the person does not is not a gate, it is an obstacle.