--- title: Checklist Workflow slug: checklist-workflow kind: topology summary: A record advances by completing a named set of prerequisites rather than by moving through stages — the process is "what is still outstanding", not "where is it". problem: >- Onboarding a client, mobilising a site or closing a month involves fifteen things that must all happen, some in parallel, by different people. A status field cannot express that, so the real state lives in a spreadsheet and nobody trusts it. family: [workflow, coordinate] data_shape: [record, collection] principles: [orientation, progressive-disclosure, surface-dont-bury] interaction: [decision, scanning] density: medium complexity: medium status: stable visibility: public use_when: - Completion means a set of things being done, not a position being reached. - Items can happen in any order, or in several orders. - Different people own different items. - The same set repeats for every record, so it is worth naming. avoid_when: - The work really is a sequence with one owner at a time. Use a linear workflow. - The list differs completely every time — that is a task list, not a process. - There are three items. A checklist adds ceremony to something already visible. alternatives: - slug: linear-workflow when: The work moves through stages in order and only one thing is happening at a time. - slug: stage-gated-workflow when: Items must be complete before a record may ADVANCE — checklist plus a gate. ask_leo: | Model this process as a checklist attached to each record. - Define the checklist as a template applied to every new record, so the same items appear every time and can be reported on across records. - Each item has a name written as a completed outcome, an owner or an owning role, and optionally a due date. - Show progress as a fraction and a bar — "9 of 14 done" — at the top of the record, and make the outstanding items the ones you can see without opening anything. - Record who completed each item and when. Completion without attribution is unauditable and, in practice, untrusted. - Let items be marked not-applicable with a reason, rather than forcing people to either tick something untrue or leave the record permanently incomplete. - Allow ad-hoc items to be added to one record without changing the template, and show that they are additions. - Roll the progress up to the collection view, so someone can see which records are furthest behind without opening each one. related: - title: Linear Workflow url: /patterns/linear-workflow summary: The sibling topology — position rather than completeness. - title: Review Queue url: /patterns/review-queue summary: What a single unowned checklist item across many records becomes. --- ## The shape ``` Client onboarding — Riverside Fit-Out 9 of 14 done ▓▓▓▓▓▓░░░ ───────────────────────────────────────────────────────────────────── ✓ Signed contract received Dana · 12 Aug ✓ Insurance certificate on file Priya · 14 Aug ✓ Purchase order raised Dana · 15 Aug ○ Site induction booked ops · due Fri ← outstanding, owned ○ Access codes issued ops ⊘ Parking permit n/a — no vehicles on site ───────────────────────────────────────────────────────────────────── ↑ not-applicable, with a reason ``` The properties that matter: - **A template**, so the same items exist on every record and can be compared across records. - **An owner per item**, because unowned items are the ones that sit. - **Attribution on completion.** Who and when, or the tick means nothing. - **A not-applicable state with a reason.** Without it, people tick things that did not happen — which is the moment the checklist stops being true. - **A rolled-up fraction** on the collection view. ## Why it is a different topology A [linear workflow](/patterns/linear-workflow) answers *where is this*. A checklist answers *what is still outstanding*. Those are different questions and they need different data: one current stage versus a set of independent completions. Trying to express a checklist as stages produces the familiar mess — statuses like "Partially onboarded" that mean different things to different people, and a spreadsheet on the side where the real state lives. ## The not-applicable state earns its keep This is the item most designs omit and the one that decides whether the checklist stays honest. With only done and not-done, a record that legitimately does not need item seven can never be complete — so somebody eventually ticks it. Once one item is ticked untruthfully, no item can be trusted, and the checklist has become decoration. A third state, with a required reason, keeps the record both complete and true. ## Getting it wrong - **Items with no owner**, which are exactly the items that never get done. - **No not-applicable state**, which trains people to tick untruthfully. - **No attribution**, so nobody can ask a follow-up question about a tick. - **A template nobody can change**, so ad-hoc reality gets recorded in email instead. - **Progress hidden inside the record**, so nobody can see which of forty clients is stalled without opening forty records. - **A checklist used as a gate without saying so** — if items block progress, that is a [stage-gated workflow](/patterns/stage-gated-workflow) and it must be explicit. ## Exemplars **Aviation and surgical checklists** are the origin, and the transferable lesson is that the value came from making the list *the same every time*, not from the individual items. Consistency is what turned it into a safety system. **Mortgage and loan onboarding software** is the clearest commercial example: dozens of independent documents and checks, several owners, and a completion fraction that drives the whole business's reporting. **GitHub pull request checks** show the roll-up done well — many independent results, one summary state, and the failing ones surfaced without opening anything. The extractable rule: **a checklist is a template plus attribution.** Without the template you cannot compare records; without attribution you cannot trust the ticks.