Order status reference

An order carries exactly one of five statuses at any time. This page is the definitive list — for the lifecycle they form and why an order lands in one or the other, see How orders work.

Note

There is no "Failed" status. It's a common assumption, but an order that can't be dispatched sits in Needs Attention, not a separate failure state — every order is always one of the five below.

The five statuses

Status	Portal label	Meaning	Enters when	Leaves when
needs_attention	Needs Attention	The order fails at least one validation check and can't be dispatched yet.	The order is created, or an existing Ready to Dispatch order is edited, and a validation check fails.	Every failing check is fixed and the order passes validation.
valid	Ready to Dispatch	The order passes every validation check and is eligible to dispatch.	The order is created, or an edited order passes validation, with no checks failing.	The order is dispatched individually, or as part of a route it's on, or an edit fails validation again.
confirmed	Confirmed	An optional explicit sign-off layered on a Ready to Dispatch order.	Someone confirms a Ready to Dispatch order.	The order is dispatched.
dispatched	Dispatched	The order has been sent out; it created a delivery that a provider or your own fleet is carrying out.	The order is dispatched — individually, through a route, or by auto-dispatch on creation.	—
archived	Archived	The order has been archived and is no longer part of active work.	The order is archived.	—

The wire value and the portal label don't always match. The one to remember is valid: internally it's still called valid, but the portal renders it as Ready to Dispatch everywhere an operator sees it. The other four statuses use the same word in both places.

Notes

Confirmed is optional, not a required step. It sits on top of valid rather than replacing it — a Confirmed order is still, underneath, an order that passed validation. Most orders never pass through Confirmed at all; they go straight from Ready to Dispatch to Dispatched. Treat it as an extra sign-off some teams choose to use, not a stage every order must clear.

Revalidation is the only automatic backward move. Editing a Ready to Dispatch order re-runs the same validation checklist that cleared it in the first place. If the edit breaks a rule — a required field gets cleared, an address becomes unresolvable — the order drops back to Needs Attention automatically. That backward move only applies to a Ready to Dispatch order being edited; it isn't something that happens to a Confirmed, Dispatched, or Archived order.

Dispatched is an end state from the status table's point of view. Nothing in the status table moves an order back out of Dispatched — from here on, changes to that work happen on the delivery the order created, not on the order's status itself. Archived orders can be restored — see Archived orders — but nothing in this table moves an order into or out of Archived automatically; archiving and unarchiving are manual actions, not status transitions the table drives.

A routed order can show Ready to Dispatch and still be on a route. Adding an order to a route doesn't change its status — a valid order that gets routed is still valid, so it keeps appearing in the Ready to Dispatch tab at the same time it shows up under Routes. Neither view is wrong. What changes is how you dispatch it: Nash won't dispatch a routed order individually — you dispatch the route it belongs to instead. If the overlap makes Ready to Dispatch noisy, filter it to Without Route to see only the orders that are actually eligible for individual or bulk dispatch.

Note

If a validation failure lands on something the order form has no field for, the order gets a Warnings tab instead of an inline error. That's a separate signal from the status itself — an order can be Needs Attention with a plain fixable error, or Needs Attention with a Warnings tab that means the fix isn't self-serve. See Fix an order that needs attention.

Related

• How orders work — the full lifecycle, why an order needs attention, and what dispatch locks down.
• Fix an order that needs attention — resolving a Needs Attention order.
• Build and manage routes — routing orders and the Without Route filter.