---
title: Linear Workflow
slug: linear-workflow
kind: topology
summary: Work moves through a fixed sequence of stages in one direction — new, review, approved, complete — with one owner at a time and no branching.
problem: >-
  A business process is real and repeatable, but the software models it as a set
  of independent records with flags. Nobody can see what stage anything is at,
  what is stuck, or whose turn it is, because the sequence exists only in how
  people happen to work.
family: [workflow]
data_shape: [record, collection]
principles: [orientation, consistency]
interaction: [navigation]
density: low
complexity: low
status: stable
visibility: public
use_when:
  - The stages are the same for every record and always happen in the same order.
  - One person or team owns the work at each stage.
  - People ask "what stage is this at?" out loud, and expect one answer.
avoid_when:
  - Records legitimately skip stages or go back and forth. That is a branching workflow, and forcing it linear makes people lie to the system.
  - Several things happen at once and converge. That is a parallel workflow.
  - There is no handoff — one person does everything in one sitting. Then it is a form, not a workflow.
alternatives:
  - slug: lifecycle-status
    when: You need the vocabulary of states first. Get that right before building movement between them.
  - slug: review-queue
    when: The interesting question is not the sequence but who works the next item at one particular stage.
ask_leo: |
  Model this process as a linear workflow.

  - Define the stages as a single ordered list, and store the current stage as
    one field on the record.
  - Allow movement to the next stage and back to the previous one. Do not allow
    arbitrary jumps unless a named role is permitted to override, and record it
    when they do.
  - Every stage names an owner — a person or a team — so "whose turn is it" is
    always answerable.
  - Record every transition with who moved it, when, and from which stage to
    which. The history is the audit trail and it is what makes the process
    improvable.
  - Show the sequence on the record so someone can see where this one is and
    what comes next, and show it the same way everywhere.
  - Make the primary action on the record the move to the next stage, named as
    the outcome — "Send for review", not "Update status".
  - Show how long the record has been in its current stage. Age is what surfaces
    stuck work.
related:
  - title: Lifecycle Status
    url: /patterns/lifecycle-status
    summary: The field this topology moves through. Name the states before building the movement.
---

## Anatomy

```
  ①  New          ②  In review     ③  Approved      ④  Complete
  ───────────     ───────────      ───────────      ───────────
  owner: sales    owner: ops       owner: finance   —
  ▸ this one has been in "In review" for 6 days
      └── age is what makes stuck work visible
```

Four properties, and a process that lacks any one of them is not really linear:

1. **A fixed order**, the same for every record.
2. **One current stage**, stored as a single field.
3. **An owner per stage**, so whose turn it is never needs asking.
4. **A recorded history** of every transition.

## Why it works

Linear is the topology worth *hoping* for, because it is the only one where the
next question is always the same: is this record moving, and if not, who is
holding it. That makes two things nearly free — a
[review queue](/patterns/review-queue) per stage, and an ageing report that
finds stuck work without anyone remembering to look.

The history is what turns it from a status field into a process you can improve.
Once transitions are recorded, "where does work actually stall" is a query
rather than an opinion, and that is usually the first genuinely surprising thing
a business learns from its own software.

## The honesty test

The most common mistake is **forcing a branching process to be linear**. The
symptom is unmistakable once you know it: people start using a stage to mean
something it does not, or they move a record forward and then edit it backwards,
or a stage called "On hold" appears that is not a stage at all.

When that happens, the process was never linear. Adding an exception path is
better than having everyone quietly lie to the system, because a system people
route around stops being a record of anything.

## Getting it wrong

- **No stage age.** Without it, a record can sit for three weeks and look
  identical to one that arrived this morning.
- **No owner per stage**, so every stall becomes a conversation.
- **A "next" button that says "Update status".** Name the outcome — the button
  is where people learn what the stage means.
- **Silent backward moves.** If work can go back, the history must say so, or
  the audit trail is fiction.

## Exemplars

**A publishing pipeline** — draft, edit, legal, scheduled, live — is the
canonical case, and shows why the owner-per-stage rule matters: four teams, and
the only interesting question is which one is holding it.

**GitHub pull requests** are linear at the core (open, merged) with everything
that is genuinely optional — review, checks, drafts — pulled out into separate
fields rather than crammed into the sequence. That separation is what keeps the
main line honest.

The extractable rule: **a linear workflow's value is the ageing, not the
sequence.** Anyone can display four stages. Knowing that stage two has held
eleven records for over a week is what changes how the business runs.