Checklist Workflow | LlamaPress Pattern Catalog
LlamaPress
Move Through Workflow
Workflow topology

Checklist Workflow

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

Move Through Workflow Coordinate

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.

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

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

Instead of this, consider

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

Linear Workflow
When: The work moves through stages in order and only one thing is happening at a time.
Stage-Gated Workflow
When: Items must be complete before a record may ADVANCE — checklist plus a gate.

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

Pattern
Linear Workflow
The sibling topology — position rather than completeness.
Pattern
Review Queue
What a single unowned checklist item across many records becomes.