Linear Workflow | LlamaPress Pattern Catalog
LlamaPress
Sign in Upload
Move Through Workflow
Workflow topology

Linear Workflow

Work moves through a fixed sequence of stages in one direction — new, review, approved, complete — with one owner at a time and no branching.

Move Through Workflow

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.

Live demo — try it Open full screen
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.

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 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.

Instead of this, consider

Same problem, different trade-off. Pick on the condition, not on taste.

Lifecycle Status
When: You need the vocabulary of states first. Get that right before building movement between them.
Review Queue
When: The interesting question is not the sequence but who works the next item at one particular stage.

Ask Leo for this

Paste this into your Leo chat. It describes the behaviour, not the code, so Leo can fit it to your data.

Prompt 
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

Pattern
Lifecycle Status
The field this topology moves through. Name the states before building the movement.