How orders work

An order is a pickup, a drop-off, and the items moving between them — the delivery work Nash hasn't committed anywhere yet. Dispatching an order creates a job, and that's the moment the work stops being a plan and starts being something a provider or your own fleet actually carries. The order itself doesn't disappear when that happens: it stays in place as the record that points to the job it created. Everything else in this article — the statuses an order moves through, why one gets stuck, what dispatch locks down — follows from that one fact.

How it works

Before dispatch, an order is just a request. You can edit almost anything on it: the pickup and drop-off details, the items, the delivery window, which dispatch strategy it uses. Nothing about it is committed to a provider, a route, or a schedule yet — it's data waiting to become work.

Dispatching an order is the action that commits it. Whether you dispatch one order at a time, dispatch a route it belongs to, or let it auto-dispatch on creation, the same underlying step runs: Nash creates a job from the order, carrying over its package, its tags, and the strategy it was configured with. The job is what actually moves through delivery — it breaks into tasks (a pickup and a drop-off), and each task's progress is what shows up as tracking for your customer.

The order doesn't get deleted or replaced. It's updated in place: its status flips to Dispatched, and it starts carrying a link back to the job it created. That link is why an order that's already gone out can still show you a Delivery ID you can click through to follow the job in progress — the order is still there, still queryable, just no longer the active record. Practically, this means "find the order" and "find the delivery" are often the same search with two different views: before dispatch you're looking at the order; after, you're one click away from the job it produced.

Important

Dispatching an order doesn't consume it. The order stays in place as a pointer to the job it created — which is why a dispatched order still opens, still shows its Delivery ID, and never disappears from your records.

That same link also protects you from an accidental double-dispatch. If a dispatch action fires twice against the same order — a retried request, a webhook that gets resent — Nash checks whether the order already carries a job link before creating anything new, rather than blindly building a second job from the same order. You won't usually notice this happening; it just means "dispatch" is safe to retry without worrying it'll quietly duplicate the work underneath you.

The order lifecycle

An order carries exactly one of five statuses at any time. The portal's labels don't always match the underlying status name — most notably, the status that means "this order is ready to go" is called valid internally but shows up in the portal as Ready to Dispatch, and there is no "Failed" status anywhere in the set.

Status	Portal label	What moves it in	What moves it out
needs_attention	Needs Attention	The order fails one or more validation checks, on creation or on any later edit	Fixing the flagged fields until the order passes validation
valid	Ready to Dispatch	The order passes every validation check	Dispatching it (directly, or via a route), or an edit that fails validation again
confirmed	Confirmed	Someone explicitly signs off on a Ready to Dispatch order	Dispatching it
dispatched	Dispatched	The order is sent out — individually, via a route, or by auto-dispatch on creation	—
archived	Archived	The order is archived	—

Confirmed is worth two sentences and no more: it's an optional, explicit sign-off you can add to a Ready to Dispatch order, layered on top of the valid status rather than a validation state of its own. Most orders never pass through it — they go straight from Ready to Dispatch to Dispatched — so don't read Confirmed as a required step in the pipeline.

The only backward move in the whole lifecycle is revalidation. Editing a Ready to Dispatch order re-runs the same checklist that cleared it in the first place, and if the edit breaks a rule — you cleared a required field, changed an address to something that can't be located — the order drops straight back to Needs Attention. There's no separate "invalid edit" state; it's the same Needs Attention tab you'd see on a brand-new order.

The order list has a sixth tab, Routes, sitting next to the five status tabs above — but it isn't a sixth status, and an order doesn't "become" Routes the way it becomes Dispatched or Archived. Selecting it swaps the whole table over to show your routes instead of filtering orders by status. An order's real status keeps whatever value it already had regardless of which tab you're looking at it through — which matters once you get to routed orders below, because a routed order can show up in both the Ready to Dispatch tab and the Routes tab at the same time, with neither view being wrong.

Why an order needs attention

Every order — new or edited — runs through the same fixed checklist before it can become dispatchable. It isn't configurable per organization and it isn't something a workflow can skip: it's a set of rules built into Nash itself, and today there are twenty-three of them. An order clears Needs Attention only when every rule passes; it takes just one failure to keep it there.

The rules cluster into categories that map to what you'd actually go fix on the order form:

• Required contact fields — a missing phone number, a missing name or business name on either side, a delivery value that wasn't set.
• Addresses — a pickup or drop-off address that can't be located or parsed, or one that resolves to the same place on both ends.
• Dispatch strategy — the strategy attached to the order is missing or no longer exists.
• Distance and vehicle — the pickup-to-drop-off distance exceeds what your organization allows, or the vehicle size requested isn't a supported size.

Beyond those four, the checklist also covers things like scheduling and timezone consistency, package and item details, and duplicate-order detection — the same rule engine, just checking different fields. Whichever rule fails, the order lands in Needs Attention with that specific problem attached to it, and clearing the one problem that's actually wrong is enough to move it forward — you don't need every rule to re-pass from scratch, just the ones currently failing.

A couple of the rules are worth knowing in concrete terms because they're the ones operators run into most: the distance check compares the straight line between pickup and drop-off against your organization's maximum allowed delivery distance, which defaults to 300 miles if your organization hasn't set its own; and the required-fields check is really several checks in one — it wants a delivery value, a phone number on both the pickup and drop-off side, and at least a first name or a business name on each side too. A single edit that fills in one missing phone number can clear that whole rule at once.

Checking isn't a single flat pass, either — Nash normalizes an order's data first (parsing the address you typed, resolving the right timezone for its location), then runs the rules against the normalized version, then reconciles the results into the specific fields you see flagged. You don't need to think about those phases day to day; what it means practically is that fixing one underlying value — a corrected address, say — can clear several flagged fields at once if they all depended on it. A small number of rules can also be switched off for an individual order, and a couple are suppressed automatically for certain order types, such as pickup-only orders — those are built-in exceptions in the rule engine itself, not something you configure at the organization level.

Most of these failures map cleanly onto a field you can see and edit on the order form, so fixing them is usually a matter of opening the order and correcting whatever's flagged. But not every failure has a home on the form.

Note

Some validation failures land on a field the order form has no input for. When that happens, the order gets a separate Warnings tab instead of an inline error you can fix yourself — and the Warnings tab is explicitly an escalation path, not a self-serve one. If you see it, the fix isn't something you can do from the order screen; reach out to your technical team or Nash support instead of hunting for a field that isn't there.

That's the real dividing line for "can I fix this myself": if the checklist flags a field you can see, you can clear it. If it flags something the form doesn't surface, the Warnings tab is where that shows up, and it's a hand-off point, not a form to fill in.

What dispatch does, and what you cannot undo

Dispatch is the same action described in the first section, seen from the order's side. When you dispatch — whether you pick a provider from quotes, send it straight through a dispatch strategy, or let auto-dispatch fire on creation — Nash builds a job from the order's package, tags, and configured strategy, sets the order's status to Dispatched, and writes the link back to that job onto the order. From that point, the order is the historical record and the job is the live one.

That handoff is also where an order's mutability ends. Before dispatch, you can edit almost anything. After dispatch, an order is read-only by default — an edit attempt is refused outright, not silently dropped or partially applied.

Warning

Dispatch is not reversible from the order side. Once an order is dispatched, you can't edit it back into shape the way you could beforehand — there's no "undo dispatch" that returns it to Ready to Dispatch for another pass. If something needs to change on work that's already gone out, that's a delivery-side or job-side change, not an order edit.

There's a narrow exception to the read-only default, and it's worth being precise about its shape rather than calling it "largely editable": a small, org-gated setting lets some organizations still adjust exactly two things on a dispatched order — the items and the delivery instructions — nothing else. Availability of this exception varies by organization; if you need it, reach out to Nash rather than assuming it's already on for you. Outside of that specific carve-out, treat "dispatched" as final for the order itself.

One more honest detail, because it's easy to misread: the order form itself doesn't visibly grey out or lock its fields once an order is dispatched. Open the edit view on a dispatched order and it can still look editable — the read-only rule is enforced when you try to save, not by disabling the inputs beforehand. Don't take an editable-looking field as a sign the change will stick; if the order is dispatched and you're outside the narrow items and delivery-instructions exception, the save will be refused even though nothing on screen warned you first.

The routed-order duality

Adding an order to a route doesn't change its status. A routed order that hasn't been dispatched yet is still, quietly, valid — the same status as any other Ready to Dispatch order — so it keeps appearing in the Ready to Dispatch tab even though it's already sitting on a route. That's not a bug or a stale view; there's no separate "routed" status for an order to move into, so nothing about being on a route removes it from the tab it's already in.

What changes is how you're allowed to dispatch it. Nash refuses to dispatch a routed order individually — the server rejects the attempt outright and tells you to dispatch the route instead. So a routed order genuinely lives in two places at once — Ready to Dispatch and Routes — but only one of them is the one you actually act on: you dispatch it through its route, and attempting to dispatch it on its own from the orders list won't work.

If that duplication makes the Ready to Dispatch tab noisy — orders you already committed to a route, still showing up alongside the ones you haven't — filter it down with Without Route, which shows only orders that aren't attached to a route yet. That's the practical way to keep the tab limited to orders that are actually eligible for individual or bulk dispatch, rather than scrolling past ones that are already spoken for.

The route itself carries a separate, mirror-image protection: once a route has been dispatched, you can no longer add more orders to it. That's a different guard from the one above — this one protects the route from being changed after it's already gone out, rather than stopping you from bypassing the route on one of its orders — but the two together mean a route is a single, coherent unit once it's dispatched: nothing joins it late, and none of its orders leave individually. If you need to add one more stop after a route is already out, that's a new order or a new route, not an edit to the one that's already moving.

What affects this

A handful of objects outside the order itself change how it behaves, without being fields you set directly on the order form each time:

Object	Where it's set	What it does here
Dispatch strategy	Automate ▸ Strategies — see dispatch strategies	Decides which provider is eligible and how one gets picked when the order dispatches, whether by hand or automatically
Delivery window	Configure ▸ Network — see delivery windows	Constrains which pickup and drop-off time slots the order can use, and what capacity and pricing apply
Zones	Configure ▸ Network — see manage zones	Determines which providers can even be considered for the order's pickup and drop-off locations
Providers	Configure ▸ Network — see manage providers	Not a field on the order itself before dispatch — eligibility is resolved through the order's dispatch strategy and zone coverage at the moment you dispatch

These combine to shape what an order can do without any of them living on the order record you're editing — which is exactly why two orders that look identical on their form can behave differently at dispatch, if the strategy, window, or zone behind them differs.

That's also why troubleshooting an order sometimes means leaving the order screen entirely. If a delivery window is full, a zone has no covering provider, or a dispatch strategy has no eligible providers left in it, the order itself can still look perfectly valid — the problem lives one layer out, in the configuration behind it, not in anything the validation checklist above checks.