--- title: "Order, Shipment, Tour & Leg Statuses – and how they update" description: "How statuses update automatically as you work, why an order's status reflects its shipments, and a quick reference of the status names on Orders/Shipments/Tours/Legs." url: "https://support.pr-4.orbit.do/en/core-features/order-shipment-tour-statuses-and-how-they-update" locale: "en" lastReviewed: "2026-10-09" --- # Order, Shipment, Tour & Leg Statuses – and how they update How statuses update automatically as you work, why an order's status reflects its shipments, and a quick reference of the status names on Orders/Shipments/Tours/Legs. > **Note:** Every `Order`, `Shipment` and `Tour` in Orbit carries a status that keeps you informed at a glance. You never set these statuses by hand: you do the work, and Orbit updates the status for you. ## Overview Statuses are how Orbit tells you where each piece of work stands. As you plan shipments, assign carriers, run tours and confirm orders, the matching status moves along with you. Because statuses follow the work rather than being typed in, they stay accurate without anyone having to remember to update them. This article explains how statuses change, how an `Order`'s status reflects the `Shipment`s inside it, and lists the status names you will see in Orbit MissionControl. **Key highlights:** * **Hands-off**: You take an action; Orbit sets the status. There is no field to fill in and no status to pick from a list. * **Immediate**: The moment your action lands, the related records update straight away. There is nothing to wait for and nothing to refresh. * **Orders summarise their shipments**: An `Order`'s status is a reflection of the `Shipment`s it contains, so it tells you how the whole booking is progressing. * **Consistent**: The same status is shown wherever a record appears, so a list view and a detail view always agree. ## Statuses follow the work In Orbit you change a status by *doing something*, not by editing the status itself. The work you and your drivers carry out is what moves each record forward: * Plan a `Shipment` onto a `Tour`, and the shipment moves from `Unrouted` to `Routed`. * Assign a carrier to a `Tour` (or let a carrier win it through dispatch), and the tour moves to `Assigned`. * A driver runs the `Tour` in Orbit Cockpit, starting it, arriving at and departing from each `Stop`, and the tour moves through `Running`. * Review a finished `Tour` in Orbit MissionControl, and it reaches `Tour Completed`. * Confirm or cancel an `Order`, and it moves to `Confirmed` or `Cancelled`. Because a status is a result of an action, you will never be asked to type one in. This is what keeps statuses trustworthy: they always describe what has actually happened. ### Running a tour moves its shipments Execution happens on the `Tour`. As a driver works through a `Tour` in Orbit Cockpit, each `Shipment` the tour carries follows along on its own, moving from `Routed` through `En Route: On the Way to Pickup` and `En Route: On the Way to Delivery`, and on to `Delivered` once the tour is finished and reviewed. You do not mark a shipment delivered yourself; driving the tour is what carries the shipment forward. ### A gentle note on `Unrouted` A brand-new `Shipment` starts as `Unrouted`. That is not a problem to fix: it simply means the shipment is waiting to be planned onto a `Tour`. It is a normal starting point, and it becomes `Routed` as soon as you plan it in. ## When an order is complete An `Order` groups one or more `Shipment`s: it is the customer's booking. Its status is a summary of those shipments, so it always reflects how the booking as a whole is getting on. A few points make this easy to read: * **A part-delivered order is still in progress.** If one shipment has been delivered but another is still on the road, the `Order` stays `Confirmed`. This is working as designed, the booking genuinely is not finished yet. * **It completes when every delivered shipment is done.** An `Order` reaches `Completed` only once every shipment it is still counting has been delivered, not on the first delivery. * **Cancelled or failed shipments do not hold it back.** A `Shipment` that has been cancelled or has failed drops out of the order's summary, so it never blocks completion. An `Order` can complete on its remaining shipments even if one was cancelled or failed. * **An order can also end as undeliverable.** Once every one of the order's shipments has ended and at least one of them has no cargo left to move, because the goods on it were written off, the `Order` reads as `Undeliverable` instead of `Completed`. Orbit derives this from the shipments, so undoing the write-off reopens the order. So if an `Order` shows a status that seems to trail one of its shipments, that is expected: the order is describing the whole set of shipments together, not just the one you last touched. ## The status names you will see Below are the statuses an operator sees in Orbit MissionControl for each record. A few views use a slightly shorter label for the same status (for example, an `Assigned` tour appears as **Upcoming** in some places). The meanings, however, stay the same. ### Order statuses | Status | What it means | | ------------------------- | -------------------------------------------------------------------------------------------------------------------------- | | `Requested` | A booking has come in but has not been accepted yet, for example a self-service order awaiting confirmation. | | `Confirmed` | The booking has been accepted; its shipments are live and being worked. | | `Waiting for Tour Review` | At least one of its shipments is finished and awaiting review. | | `Completed` | Every shipment that counts has been delivered. | | `Undeliverable` | Every one of its shipments has ended and at least one has no cargo left to move, because the goods on it were written off. | | `Cancelled` | The booking was called off. | ### Shipment statuses | Status | What it means | | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Unrouted` | Not yet planned onto a `Tour`, waiting to be scheduled. | | `Partially Routed` | Carried in stages, with some stages planned onto a `Tour` and some not yet. | | `Routed` | Planned onto a `Tour`, ready to be carried out. | | `En Route: On the Way to Pickup` | The driver is on the way to collect the load. | | `En Route: On the Way to Delivery` | The load has been collected and is on its way to the delivery point. | | `Waiting at Hub` | The load has been set down at an intermediate stop and is waiting for its next stage to collect it. A planned pause, not a fault. | | `Waiting for Tour Review` | The tour carrying it has finished and is awaiting review. | | `Delivered` | Successfully delivered. | | `Failed` | The delivery could not be completed. This is not a dead end: retrying the stage or returning the cargo clears it, and the shipment recovers by itself. A shipment whose cargo has been written off closes here as undeliverable, and stays there. | | `Cancelled` | The shipment was called off, or every load on it moved to a return shipment. The record is kept for your history. | When no loads remain to move, Orbit MissionControl shows a shipment with delivered loads and failed or written-off loads as `Partially Delivered`; the stored shipment status remains `Failed`. One further status belongs to the cargo rather than to the shipment. A `Load` that can never be delivered is written off, and reports the status `Perished` through the API. A write-off moves nothing and creates nothing: the `Shipment` holding that load closes as undeliverable, while delivered loads on the same shipment stay delivered. See the [Writing Off Goods That Cannot Be Delivered](https://support.pr-4.orbit.do/en/multi-leg-logistics/writing-off-goods-that-cannot-be-delivered) article. ### Leg statuses A `Leg` is one stage of a shipment's journey. Every shipment has at least one, so a shipment carried straight from pickup to dropoff has a single leg covering the whole journey. These statuses come into view once a shipment is carried in stages, see the [Legs](https://support.pr-4.orbit.do/en/multi-leg-logistics/legs-how-a-shipment-is-carried) article for how legs make up a journey. | Status | What it means | | ---------------------------------- | -------------------------------------------------------------------------------- | | `Unrouted` | Not yet planned onto a `Tour`. A normal resting state. | | `Routed` | Planned onto a tour, which has not started moving it yet. | | `En Route: On the Way to Pickup` | The tour is running and heading for this leg's pickup. | | `At Pickup` | The driver has arrived at the pickup. | | `En Route: On the Way to Delivery` | The loads are aboard and on their way to this leg's dropoff. | | `At Delivery Stop` | The driver has arrived at the dropoff. | | `Delivered` | This leg is complete. Its loads reached its dropoff. | | `Failed` | This leg could not be completed. The record is kept, and the leg can be retried. | | `Cancelled` | This leg was called off before it began. | A shipment's status follows the least advanced of its legs, so a shipment never reports more progress than the stage that is furthest behind. ### Tour statuses | Status | What it means | | ----------------- | ---------------------------------------------------------------------------------------------------------------- | | `Not Assigned` | No carrier yet: the tour is waiting to be dispatched. | | `Assigned` | A carrier (usually with a driver and vehicle) is attached; not yet started. Shown as **Upcoming** in some views. | | `Running` | The driver has started and is working through the stops. | | `Review Required` | The driver has finished the last stop; the tour is awaiting review. | | `Tour Completed` | Reviewed and closed. | | `Tour Cancelled` | The tour was called off. The record is kept for your history. | ### Live progress on a running tour While a `Tour` is **Running**, its status does not change with every stop. Instead the tour carries a finer-grained **substatus** that tells you exactly where the driver is right now. Like every other status, it follows the driver’s work in Orbit Cockpit and is never set by hand: * **Arrived at stop**: the driver has arrived at a stop. Orbit records which stop it is and when the driver got there. * **Departed from stop**: the driver has finished the stop and moved on. The tour is on its way to the next stop. One further substatus appears before a carrier is attached: while a tour is still **Not Assigned** and has been offered to carriers, it shows as **In callout**. The tour is out on the Marketplace waiting for a carrier to accept or win it. As soon as a carrier is assigned, the substatus clears and the tour moves to **Assigned** as usual. The substatus is what powers the live stop-by-stop view in Orbit MissionControl, and it is also available programmatically alongside the tour status. ## Example An operator at Orion Industries books an `Order` with two `Shipment`s: one from Lisbon to Madrid, and one from Lisbon to Barcelona. The operator confirms the `Order`, so it moves to `Confirmed`, and plans both shipments onto `Tour`s, which moves each shipment to `Routed`. As each driver runs their `Tour` in Orbit Cockpit, the matching `Shipment` moves through the `En Route` stages on its own. No one edits a status. The Madrid shipment is delivered first, but the `Order` stays `Confirmed`, because the Barcelona shipment is still on the road. Once the Barcelona driver finishes and the operator reviews that `Tour` in Orbit MissionControl, the second `Shipment` reaches `Delivered` and the `Order` moves to `Completed` by itself. Had the Barcelona shipment been cancelled instead, the `Order` would still have completed on the Madrid delivery alone. ## FAQ **Q: Can I set a status manually?** Almost never. You do the work (plan, assign, run the tour, confirm, cancel), and Orbit applies the right status. The one exception is completing a confirmed order that has no shipments, such as an equipment hire, a sale of packaging or a brokered service in which nothing is transported: use **Complete Order**, on the order's detail page or its context menu in the orders list, to set it to Completed yourself, since there is no shipment to derive that from. **Q: My order still shows Confirmed even though one of its shipments was delivered. Is something wrong?** No, this is working as designed. An `Order` reflects all of its shipments together, so it stays `Confirmed` until every shipment that counts has been delivered. A part-delivered order is correctly still in progress. **Q: One of my shipments failed, yet the order still completed. How?** A cancelled or failed `Shipment` drops out of the order's summary, so it does not block completion. Once the remaining shipments are all delivered, the `Order` completes. Where a shipment ended with its cargo written off, the order reads as `Undeliverable` instead of completing. **Q: My shipment shows Failed. How do I clear it?** By acting on the stage that failed: retry it, or move the cargo onto a return shipment. The status then clears by itself. See the [When a Delivery Fails](https://support.pr-4.orbit.do/en/multi-leg-logistics/when-a-delivery-fails-what-to-do-next) article. A shipment whose cargo was written off is the exception: those goods will never travel again, so it stays closed as undeliverable unless the write-off is undone. **Q: How soon do statuses update?** Straight away. When your action lands, the related `Shipment`s and `Order`s update in the same step. There is nothing to wait for or refresh. **Q: Why does the same status look slightly different in different places?** A few views use a shorter label for the same status (for example, `Assigned` may appear as **Upcoming**). The underlying meaning is always the same. **Q: My shipment shows Waiting at Hub or Partially Routed. What do those mean?** Both belong to a shipment carried in stages. `Waiting at Hub` means its load has been set down at an intermediate stop and is waiting for the next stage to collect it; `Partially Routed` means some stages are planned and some are not yet. See the [Legs](https://support.pr-4.orbit.do/en/multi-leg-logistics/legs-how-a-shipment-is-carried) article. **Q: I have never split a shipment. Do I need the leg statuses?** Not in practice. A shipment carried straight through has a single `Leg` spanning its whole journey, and you plan and follow it exactly as you would any shipment. **Q: Can I read statuses outside Orbit MissionControl?** Yes. Statuses are available programmatically for integrations. See the Orbit API Reference for the available fields and values.