Orders at a glance

An order is the work you want done, before it's been sent anywhere: a pickup, a drop-off, and the items moving between them. It's a request, not yet a delivery — everything about it is still yours to shape. You can edit almost any part of an order right up until you dispatch it. Dispatching is the action that commits an order: it creates the job that a provider or your own fleet actually carries out, and from that point the order stops being something you edit and becomes the record of what you asked for. Most of what makes orders worth understanding as their own object follows from that one line — before dispatch, an order is a plan you can still change; after, it's history pointing at the work in progress.

What you can do with orders

Working an order moves through a handful of everyday tasks, each with its own place to start:

• Find and work orders — search, filter, and save views over your order list so you can get back to the ones you care about.
• Read an order — open an order to see everything on it: pickup and drop-off details, items, status, and history.
• Create and schedule orders — add orders one at a time or in bulk, and decide when each one should move.
• Resolve orders — fix the orders that need attention before they're eligible to go out.
• Dispatch orders — send an order out, individually or in bulk, and turn it into a job a provider or your fleet carries.
• Archived orders — find orders you've set aside, and bring one back if you archived it by mistake.

Those six cover the order's whole working life: it starts out findable, gets read and edited while it's still a plan, gets fixed if something's wrong with it, gets dispatched when it's ready, and eventually gets archived once you're done with it. You don't have to touch every stage on every order — a lot of orders never need to be resolved, for instance — but whichever one you're on, there's a dedicated place to do it.

Learn how it works

The task pages above tell you what to click. For the mechanics behind them — why an order's status changes, what dispatch locks down, why a routed order can show up in two places at once — see How orders work. It walks through the full lifecycle: the checks an order has to pass before it's dispatchable, what happens the moment you dispatch it, and what stays editable afterward.

Two reference pages fill in the details you'll want while you're actually looking at an order:

• Order status reference — every status an order can carry, what the portal calls it, and what moves it from one to the next.
• Order fields reference — every field you can see and set on an order, tab by tab.

One thing worth carrying into all of this: Nash dispatches the order and hands it to a provider or your own fleet — Nash itself doesn't carry the delivery. What you're managing on this side is the request and its status, not the drive itself.