Step statuses field definitions
Step status
Every step on a work order has a Status that controls what the routing engine and the operator can do with it. It shows in the Status column on the routing-steps table.
| Status | What it means | Operator can... |
|---|---|---|
| PENDING | Locked. Waiting for prior priority groups to finish. | Wait - the engine will activate it. |
| ACTIVE | Currently executable by a user (or an automated handler). | Process / complete / pause. |
| PAUSED | Started but blocked - either system-paused (waiting on a child, e.g. a delivery) or user-paused with a reason. Holds its priority slot, so downstream steps do not advance. | Resume once the blocker is gone. |
| AUTO_RETRY | Has done what it can and is waiting on an external condition (e.g. a parked Sales Shipment with no stock). Rechecked every 5 minutes. | Wait - or fix the external cause. |
| ERROR | An exception was thrown at start-up or completion. Needs review. | Clear error (-> ACTIVE, retry complete) or Retry from error (-> PENDING, re-runs start-up). |
| COMPLETED | Finished. Read-only. | - |
| CANCELLED | Aborted (individually, or because the WO was cancelled). Read-only. | - |
Lifecycle in plain English: PENDING -> ACTIVE -> COMPLETED. From ACTIVE a step can also go to PAUSED (then back to ACTIVE on resume), to AUTO_RETRY (then back to ACTIVE on a timer recheck), or to ERROR. From ERROR, Clear error returns it to ACTIVE and Retry from error returns it to PENDING to re-run its start-up. Any non-COMPLETED step becomes CANCELLED when the WO is cancelled.
Fulfillment status
A secondary flag on steps that involve material - Repair Tasks, Assembly Tasks, Material lines. It tracks the physical state of the parts the step needs, independent of the main status.
| Fulfillment | What it means |
|---|---|
| PENDING | Not yet looked at by the system. |
| READY | Stock is in the local bin (workbench / area) and ready to pick. |
| AWAITING_DELIVERY | Requested from stores - a delivery request has been spawned and we are waiting for it. |
| BACKORDER | Not in stock anywhere - a procurement / production decision is needed. |
| PICKED | Physically at the bench - the operator has it in hand. |
The My Assembly Tasks queue uses these to show shortages at a glance: a task with BACKORDER parts shows a red shortage chip; one with everything PICKED is ready to roll.
Pause: who can do it and why
- System pause - the engine pauses a step automatically when it needs a child to complete first (e.g. a Repair Task that requested stock spawns a Delivery Request and pauses on it). Resumes automatically when the child completes.
- User pause - allowed only on certain task handlers (Repair Task, Assembly Task); the operator must enter a reason, which shows in the Status cell of My Repair Tasks so the team knows why the bench is idle.
ERROR: why a step can land there
- A handler threw an unchecked exception (a database constraint, a network timeout, a missing prerequisite).
- An auto-completing handler could not finish its start-up work (e.g. a Sales Shipment Create could not reach Unleashed).
- A spawned child step failed to activate.
The technical reason is captured in a STEP_ERROR activity event on the WO; the public customer-tracking page filters those out, so the customer never sees raw errors.
Tips
- PAUSED holds its priority slot. A WO with one paused step at priority 30 will not activate priority 40 until that step resumes or completes. This is the number-one reason a WO seems "stuck".
- AUTO_RETRY is not a failure - it is the system being patient, typically a sales-shipment line waiting for stock to arrive.
- Clear error vs Retry from error: Clear error keeps the half-done state (fix something, then click Complete again) - right when the failure was during completion. Retry from error starts the step over from scratch - right for auto-completing steps whose work happens entirely at start-up (Send Tracking Email, Leave Finalise, and similar).