{"slug":"linear-workflow","meta":{"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.\n\n- Define the stages as a single ordered list, and store the current stage as\n  one field on the record.\n- Allow movement to the next stage and back to the previous one. Do not allow\n  arbitrary jumps unless a named role is permitted to override, and record it\n  when they do.\n- Every stage names an owner — a person or a team — so \"whose turn is it\" is\n  always answerable.\n- Record every transition with who moved it, when, and from which stage to\n  which. The history is the audit trail and it is what makes the process\n  improvable.\n- Show the sequence on the record so someone can see where this one is and\n  what comes next, and show it the same way everywhere.\n- Make the primary action on the record the move to the next stage, named as\n  the outcome — \"Send for review\", not \"Update status\".\n- Show how long the record has been in its current stage. Age is what surfaces\n  stuck work.\n","related":[{"title":"Lifecycle Status","url":"/patterns/lifecycle-status","summary":"The field this topology moves through. Name the states before building the movement."}]},"body":"## Anatomy\n\n```\n  ①  New          ②  In review     ③  Approved      ④  Complete\n  ───────────     ───────────      ───────────      ───────────\n  owner: sales    owner: ops       owner: finance   —\n  ▸ this one has been in \"In review\" for 6 days\n      └── age is what makes stuck work visible\n```\n\nFour properties, and a process that lacks any one of them is not really linear:\n\n1. **A fixed order**, the same for every record.\n2. **One current stage**, stored as a single field.\n3. **An owner per stage**, so whose turn it is never needs asking.\n4. **A recorded history** of every transition.\n\n## Why it works\n\nLinear is the topology worth *hoping* for, because it is the only one where the\nnext question is always the same: is this record moving, and if not, who is\nholding it. That makes two things nearly free — a\n[review queue](/patterns/review-queue) per stage, and an ageing report that\nfinds stuck work without anyone remembering to look.\n\nThe history is what turns it from a status field into a process you can improve.\nOnce transitions are recorded, \"where does work actually stall\" is a query\nrather than an opinion, and that is usually the first genuinely surprising thing\na business learns from its own software.\n\n## The honesty test\n\nThe most common mistake is **forcing a branching process to be linear**. The\nsymptom is unmistakable once you know it: people start using a stage to mean\nsomething it does not, or they move a record forward and then edit it backwards,\nor a stage called \"On hold\" appears that is not a stage at all.\n\nWhen that happens, the process was never linear. Adding an exception path is\nbetter than having everyone quietly lie to the system, because a system people\nroute around stops being a record of anything.\n\n## Getting it wrong\n\n- **No stage age.** Without it, a record can sit for three weeks and look\n  identical to one that arrived this morning.\n- **No owner per stage**, so every stall becomes a conversation.\n- **A \"next\" button that says \"Update status\".** Name the outcome — the button\n  is where people learn what the stage means.\n- **Silent backward moves.** If work can go back, the history must say so, or\n  the audit trail is fiction.\n\n## Exemplars\n\n**A publishing pipeline** — draft, edit, legal, scheduled, live — is the\ncanonical case, and shows why the owner-per-stage rule matters: four teams, and\nthe only interesting question is which one is holding it.\n\n**GitHub pull requests** are linear at the core (open, merged) with everything\nthat is genuinely optional — review, checks, drafts — pulled out into separate\nfields rather than crammed into the sequence. That separation is what keeps the\nmain line honest.\n\nThe extractable rule: **a linear workflow's value is the ageing, not the\nsequence.** Anyone can display four stages. Knowing that stage two has held\neleven records for over a week is what changes how the business runs.\n"}