Skip to content

Work Order Lifecycle

A work orderWork OrderA planned production run: pick materials, build the items, do QC, and complete — all tracked together. Use work orders when you're building stock ahead of demand or running a multi-day project. Read more → moves through up to eight statuses from creation to completion. Every transition is recorded — who did it, when, and any note they left — so you always have a full history.

The work order header with a six-segment status stepper showing the current status as 'In Progress'.
The status stepper at the top of every detail page tells you where the work order is in its lifecycle.
  • The eight statuses
  • The transition map
  • Quick Start and Quick Complete shortcuts
  • The “back” action
  • Cancel and reopen
  • Guards that block transitions
  • The audit log
StatusWhat it meansPlan editable?Build runs allowed?
draftPlan is being assembled. No execution yet.YesNo
readyPlan is locked-as-final but you haven’t started building.YesNo
in_progressBuild runs may be created. Working state.YesYes
pausedSuspended. New build runs are blocked, but the canvas remains editable.YesNo
quality_controlBuilt items are awaiting a QC review.YesYes (rework runs)
qc_approvedAll built items have passed QC. Eligible for completion.YesYes
completedTerminal-with-undo. Plan is frozen.NoNo
cancelledTerminal-with-undo. Plan is frozen.NoNo

completed and cancelled are terminal but reversible. There’s no “delete” without first cancelling.

draft ──ready_to_start──> ready ──start──> in_progress
│ │ │
│ └──revise_plan─────┘
│ │
└────quick_start────────────────────────> in_progress
├─ pause ──> paused ──resume──> in_progress
├─ submit_for_qc ──> quality_control
│ │
│ ├─ approve_qc ──> qc_approved
│ │ │
│ │ ├─ mark_complete ──> completed
│ │ │
│ └─ reject_qc ──> in_progress
└─ mark_complete ──> completed (no QC, "Quick Complete")
cancel: any non-terminal status ──> cancelled
uncancel: cancelled ──> previous status

There are 15 named transitions. The most common ones in everyday use:

TransitionWhat it does
ready_to_startdraft → ready — locks the plan as final but doesn’t start work.
startready → in_progress — work begins.
quick_startdraft → in_progress — combines mark-ready and start in one click.
pause / resumePause and resume work.
submit_for_qcin_progress → quality_control — send built units for review.
approve_qc / reject_qcPass or fail the QC phase.
mark_completein_progress → completed (no QC) or qc_approved → completed.
cancelStop the work order without completing.
uncancelBring a cancelled work order back to its previous status.
uncompleteReverse a completion.

Two transitions exist specifically to skip optional waypoints:

  • Quick Start (quick_start) — go from draft straight to in_progress, bypassing ready. Available from the create dialog’s Save & start button and from the row menu on a draft.
  • Quick Complete — go from in_progress straight to completed, bypassing QC. Available from the action row on an in-progress work order. There’s no separate transition name; it uses mark_complete from in_progress and just doesn’t run any QC reviews along the way.

Quick Complete is only available if you haven’t already created any QC reviews for the work order. Once a single QC review exists, the QC guards activate and Quick Complete is no longer offered.

Most transitions have a corresponding reverse. Rather than hunting for the right named transition, the action row offers a single Back button. It walks the canonical chain:

ready → draft
in_progress → ready
quality_control → in_progress
qc_approved → quality_control

For terminal statuses (completed, cancelled), Back reads the previous status that was captured when the work order entered its current state, so a completion that came from qc_approved walks back to qc_approved, while a completion that came directly from in_progress walks back to in_progress.

You can cancel from any non-terminal status. The cancellation does not auto-cancel related entities — open build runsBuild RunOne cycle of assembly inside a work order: pick the materials, build the units, then complete (or cancel, or reverse). A work order can have many build runs over its life — each one moves a defined quantity of inventory and writes a row to the audit ledger. Read more → stay in their picking state and need to be cancelled separately. The same goes for QC reviews; cancellation doesn’t touch them.

uncancel brings the work order back to whichever status it was in before it was cancelled. Soft-deleted work orders (cancelled and then deleted) cannot be revived — see creating a work order → deleting.

Each transition runs a small set of pre-flight checks. Common ones:

  • Plan complete (on ready_to_start and quick_start): at least one item, a production location, and no active material with a zero or negative effective quantityEffective QuantityThe quantity actually consumed by the work order, after operator overrides. Starts equal to the original BOM quantity, but can be adjusted up or down per material as plans change. The effective quantity is what the pick list and cost calculations use. Read more → .
  • No open build runs (on mark_complete): if any build run is still in picking, you must complete or cancel it before marking the work order complete.
  • Items below planned (on mark_complete): every item must have completedQuantity ≥ plannedQuantity. If a build run produced fewer units than planned, you can’t complete until you build more or lower the planned quantity.
  • QC sign-off (on mark_complete, only if at least one QC review exists): every built unit must have a dispositionDispositionA QC reviewer's verdict on a built unit: how many were approved, how many were failed, and an optional reason and category for the failure. One row per item per QC review, written when the operator finalises the review. Read more → , no items can still be in reworkReworkRe-running failed units through a fresh build cycle to fix them. Rework runs don't consume new materials — the materials were already consumed in the original run. Once a rework run passes QC, the units land in finished stock. Read more → , and every built build run must have been QC-reviewed.

If a guard blocks you, the action row surfaces the specific reason in plain language so you know which sub-condition needs fixing.

If two operators open the same work order in two browsers and both edit it, only one save wins — the other gets a “this work order changed under you” notice and the page reloads with the latest state. This stops one operator from silently overwriting the other’s work.

Every transition writes a row to the work order’s lifecycle events. The detail page’s Activity Log tab merges these with build-run events into a single timeline:

  • Who took the action
  • When it ran
  • The transition name (start, pause, mark_complete, …)
  • An optional note left by the actor

Lifecycle events are append-only — they’re never edited or deleted, even if the work order is later soft-deleted.