Step statuses field definitions

Step status

Every step on a work order has a Status value that controls what the routing engine and the operator can do with it. The status appears in the Status column on the routing-steps table on processWorkOrder.xhtml.

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 by an automated handler).	Process / complete / pause.
`PAUSED`	Started but blocked. Either system-paused (e.g. waiting on a child delivery) or user-paused with a reason. Holds its priority slot — downstream steps don't advance.	Resume once the blocker is gone.
`AUTO_RETRY`	The step has done what it can but is waiting on an external condition (e.g. parked Sales Shipment with no stock). The system rechecks every 5 minutes.	Wait — or fix the external cause.
`ERROR`	An exception was thrown during `onStart` or `onComplete`. Needs operator review.	Use Clear error (→ ACTIVE, retry complete) or Retry from error (→ PENDING, re-runs onStart).
`COMPLETED`	Finished.	Read-only.
`CANCELLED`	Aborted (either individually or because the WO was cancelled).	Read-only.

Lifecycle in plain English

PENDING ──► ACTIVE ──► COMPLETED
              │
              ├──► PAUSED ──► ACTIVE  (resume)
              ├──► AUTO_RETRY ──► ACTIVE  (timer recheck)
              ├──► ERROR ──► ACTIVE  (clear error — retry complete)
              └──► ERROR ──► PENDING ──► ACTIVE  (retry from error — re-runs onStart)

Any non-COMPLETED status ──► 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 or Central — a delivery request has been spawned and we're waiting for it.
`BACKORDER`	Not in stock anywhere — a procurement / production decision is needed.
`PICKED`	Physically at the bench — the technician 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.

Priority

A WO can also carry a priority value that doesn't affect step execution order but does drive how it sorts in lists and how loud notifications get.

Priority	Used for
`LOW`	Best-effort.
`NORMAL`	Default.
`URGENT`	Promote ahead of NORMAL in queues.
`CRITICAL`	Highest visual priority. SLA-critical work.

Note: this is the WO-level priority, separate from the executionPriority integer that orders steps inside one WO. They're easy to confuse — one is about urgency, the other about routing sequence.

Pause: who can do it and why

System pause — the engine pauses a step automatically when the step 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 — only allowed on certain task handlers (Repair Task, Assembly Task) and the operator must enter a pause reason. The reason 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 (database constraint, network timeout, missing prerequisite).
An auto-completing handler couldn't finish its onStart work (e.g. Sales Shipment Create can't 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 events out so the customer never sees raw stack traces.

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's the system being patient — typical use is sales-shipment lines waiting for stock to arrive in Unleashed.
Clear error vs. Retry from error: Clear error is the right choice when the failure was during completion (you want to keep the half-done state, fix something, then click Complete again). Retry from error is the right choice when the work happens entirely in onStart and you want to start over — works for auto-completing handlers like Send Tracking Email, BMSEX Zero-cost SO, Leave Finalise.