--- title: "Load Status Tracking" description: "How each load carries its own handling outcome, how drivers and operators confirm it when departing a stop, and what a failed load means for the shipment." url: "https://support.pr-4.orbit.do/en/core-features/load-status-tracking" locale: "en" lastReviewed: "2026-10-02" --- # Load Status Tracking How each load carries its own handling outcome, how drivers and operators confirm it when departing a stop, and what a failed load means for the shipment. > **Tip:** Load Statuses enable granular tracking of individual loads throughout their transport lifecycle. Orbit records the handling outcome for each load separately — giving you full visibility into what was loaded, unloaded, or left behind at every stop along a tour. ## Overview Every `Load` on a `Tour` carries its own status that reflects its current position in the transport process. When a driver departs from a stop, they confirm the handling outcome for each load scheduled for pickup or dropoff at that stop. Load statuses are visible across the entire Orbit platform — in Orbit MissionControl, Orbit Connect, and Orbit Cockpit — and are included in webhook payloads, making them available to external systems. > **Key highlights:** **Per-load tracking**: Each load carries its own status, independent of other loads at the same stop > > **Driver-confirmed**: Statuses are set explicitly by the driver when departing from a stop, ensuring accurate records > > **Barcode scanning support**: Drivers can use the Cockpit barcode scanner to quickly identify and confirm loads > > **Full history on the Shipment**: The Shipment maintains a complete status log across all transport attempts of a load > > **A note on a successful handover**: A load can be collected or delivered with a note, so a difference is recorded without calling the handover a failure ## Load Status Lifecycle A load progresses through a defined set of statuses as it moves through the transport process: | Status | Description | | ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Routed** | The load has been assigned to a Tour but has not yet been handled. This is the initial status. | | **Loaded** | The load was successfully picked up at the pickup stop. | | **Unloaded** | The load was successfully delivered at the dropoff stop. | | **Not Loaded** | The load could not be picked up at the pickup stop (e.g. damaged, missing, or refused). | | **Not Unloaded** | The load could not be delivered at the dropoff stop (e.g. refused by the recipient). It stays on the vehicle. | | **Carried Back** | The load was refused at its dropoff, stayed on the vehicle, and was later put down at one of your organisation's cross-dock hubs. It is no longer aboard and is waiting at that hub. | | **Returned** | The load was moved onto a return shipment, which now carries it. It no longer travels on this transport. | | **Written Off** | The load can never be delivered, either because it cannot be found at all or because it still exists but is no longer deliverable. Nothing carries it onward. Reported through the API as `Perished`. | ### Status Flow The status of a load follows a strict progression: ``` ┌─── Loaded ───┬─── Unloaded │ │ Routed ────────────┤ └─── Not Unloaded ─── Carried Back │ └─── Not Loaded ``` At the **pickup stop**, a load transitions from `Routed` to either `Loaded` (success) or `Not Loaded` (failure). At the **dropoff stop**, a loaded item transitions from `Loaded` to either `Unloaded` (success) or `Not Unloaded` (failure). `Not Loaded` and `Not Unloaded` end the load's progress on that tour: it cannot go further on the same run. They are not the end of the story. An operator can retry the stage, which returns the load to `Routed` for a fresh attempt, or move it onto a return shipment, after which it reads `Returned`. A load refused at its dropoff is a special case, because it never left the vehicle. Before it can be redelivered or returned, Orbit needs to know where it was put down: once it is recorded at a cross-dock hub it reads `Carried Back`, and the recovery choices follow from there. 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. Some goods will never travel again, whatever is attempted: a pallet that has gone bad, or a crate that cannot be found anywhere. Those are written off rather than retried or returned. A write-off is recorded against the single `Load` it concerns, and creates no onward movement of its own. 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. ### Failure Reasons When a load is marked as `Not Loaded` or `Not Unloaded`, the driver can optionally provide a reason: | Reason | Description | | ---------------- | ---------------------------------------------------------- | | **Load Damaged** | The load was found to be damaged and could not be handled. | | **Load Missing** | The load was not present at the expected location. | | **Load Refused** | The load was refused by the receiving party. | | **Other** | A reason not covered by the above options. | In addition to selecting a predefined reason, the driver can enter a free-text comment to provide further context. Because the reason is optional, a failed load may show no reason at all; this is a gap in what was reported, not a fault in the record. ### Notes on a Successful Load Not every difference is a failure. A pallet can arrive with a dented corner and still be accepted, and a receiver can take part of a quantity without refusing the rest. Recording those as `Not Unloaded` would say the goods never arrived, which is not what happened. Instead the load is marked `Loaded` or `Unloaded` as normal and carries a note describing the difference. On a successful load, **Complete with note** offers an optional **Deviation**: | Deviation | Description | | --------------------- | ---------------------------------------------------------------------------------- | | **Accepted damaged** | The goods were damaged and the receiving party took them anyway. | | **Packaging damaged** | The packaging was damaged, with no indication that the goods themselves were. | | **Partial quantity** | Part of the expected quantity changed hands and the handover still counts as done. | | **Other** | A difference not covered by the above options. | Alongside the deviation, a free-text note can be added, and in Orbit Cockpit a photograph of the load. All three are optional and independent: a note can be left without a deviation, and a deviation without a note. The photograph attaches to that individual `Load`, which is what distinguishes it from the handover photographs taken during a signing ceremony. A note never changes the outcome. The load stays `Loaded` or `Unloaded`, the `Shipment` is unaffected, and nothing waits for an operator. It records what the driver saw, so that a later claim can be answered from the record. Notes on successful loads appear: * on the stop's load list in Orbit MissionControl, Orbit Connect and Orbit Cockpit, beside the load's status * on the **Tour Review** page in Orbit MissionControl, which counts them as **Loads with note** so a tour carrying one is easy to spot * on the Signing Summary the recipient reads, and on the delivery or collection receipt rendered from it * in Orbit Hub, where the shipper sees the deviation on the load. The free-text note stays internal * in webhook payloads, alongside the load's status > **Warning:** A note is available only on a successful outcome. On a failed load the failure reason and its comment do that job, and a note sent with a failure is ignored. ## How Load Statuses Are Updated Load statuses are updated **when departing from a tour stop**. This is the operationally meaningful point at which it can be determined whether the planned actions at a stop (loading or unloading specific items) were carried out successfully. Statuses cannot be updated outside the departure flow — they are tied to the tour advance action. ### In Orbit Cockpit When a driver initiates a departure from a stop in Cockpit, a **load status panel** slides up from the bottom of the screen. This panel lists all loads that require handling at the current stop, grouped by action (pickup or dropoff). For each load, the driver sees: * The load description, dimensions, and weight * Two buttons: one to mark the load as **successfully handled** and one to mark it as **failed** **Marking a load as successful** sets the status to `Loaded` (at a pickup stop) or `Unloaded` (at a dropoff stop). Where the load changed hands with a difference worth recording, **Complete with note** adds a deviation, a note and a photograph to that successful outcome without failing it. **Marking a load as failed** opens a modal where the driver can optionally select a failure reason and add a comment. The status is set to `Not Loaded` (at a pickup stop) or `Not Unloaded` (at a dropoff stop). A **"Mark All Successful"** button is available for situations where all loads at the stop were handled without issue. This allows drivers to quickly confirm all loads at once while still maintaining explicit per-load records. The driver must confirm the status of every load at the stop before the departure can proceed. #### Cargo carried from an earlier stop A load refused earlier on the same tour is still aboard the vehicle. If the tour later calls at one of your organisation's cross-dock hubs, that load appears in the panel again when the driver departs that stop — under its own heading, apart from the work scheduled for the stop, so it is never mistaken for one of the stop's own pickups or dropoffs. Ticking it records that the goods were put down at that hub, and the load reads `Carried Back`. Leaving it untouched is equally valid — the driver may be carrying it further — and does not hold up the departure. These items sit outside the stop's completion count for the same reason: the count covers the work planned for that stop, so confirming it says nothing about cargo that merely arrived on the vehicle. Each refused load stays an explicit choice, and completing the stop never implies that all of it was put down. #### Barcode Scanning Cockpit includes a barcode scanner that serves as a fast alternative to selecting loads from the list manually. When the scanner is active, the driver points the camera at a barcode or QR code on a package. The system identifies the corresponding load and displays a confirmation card. The driver then taps the success or failure button on this card — the same interaction as in the list view. **Scanning identifies the load, but the driver decides the outcome.** No status is set automatically by scanning alone. > **Tip:** The scanner supports the following barcode formats: > > * **QR Code** > * **Code 128** > * **Data Matrix** **How barcode matching works:** When a barcode is scanned, the system attempts to identify the corresponding load using the following steps, in order: 1. **Orbit Resource Number (**`ORN`**)** — If the barcode contains a valid `ORN`, the load is uniquely identified. This is the recommended approach for labels generated through Orbit's Document Engine ([learn more about ORNs here](https://support.pr-4.orbit.do/en/advanced-features/orbit-resource-number-orn)) 2. **Load ID** — The scanned value is checked against the IDs of all loads at the current stop. 3. **Load properties** — The scanned value is matched against the load reference, description and property fields of loads at the current stop. If the scanned barcode matches a load at a **different stop** on the same tour, a message informs the driver which stop the load belongs to. If no match is found at all, an error message is displayed. ### In Orbit Connect and Orbit MissionControl When an operator triggers a departure from a stop in Orbit Connect or Orbit MissionControl, a **confirmation modal** appears. This modal lists all loads at the current stop with a status selector for each. For each load, the operator can toggle between **success** and **failure**. When failure is selected, input fields for a failure reason and an optional comment appear inline. On success the same place offers **Complete with note**, for a deviation and a note on a load that was handled but not quite as booked. Photographs of an individual load are taken in Orbit Cockpit. A **"Mark All Successful"** option and a progress indicator showing how many loads have been confirmed are available. The departure can only be confirmed once all loads have a status. Cargo refused earlier on the tour is offered here as well, when the stop being departed is one of your cross-dock hubs, and behaves exactly as it does in Orbit Cockpit. ## Viewing Load Statuses Once statuses have been set, they are visible across the Orbit platform: * **Tour detail pages** — In Orbit MissionControl, Orbit Connect, and Orbit Cockpit, each completed stop shows the status of its loads with colour-coded indicators. Failed loads display their failure reason and comment, and a load completed with a note displays its deviation, the note and any photograph. * **Shipment detail pages** — In Orbit MissionControl, the loads section of a shipment shows a status badge for each load. Hovering over the badge reveals the full status history, including timestamps and the associated tour. ## Tour Reset and Status Reversal ### Reverting a single advance When a tour advance is reverted (undone), the affected loads return to their previous status. > **Tip:** * A load that was marked as `Loaded` at the reverted stop returns to `Routed`. > * A load that was marked as `Unloaded` at the reverted stop returns to `Loaded`. > * A load that was marked as `Not Loaded` or `Not Unloaded` returns to its previous status as well. > > Failure reasons and comments are cleared during reversal, and so are notes recorded on a successful load, including their deviation and comment. A reverted load carries no handling record until it is confirmed again. ### Full tour reset When a tour is fully reset, **all tracked loads return to** `Routed`, regardless of their current status. All failure information is cleared. The status history on the Shipment is adjusted accordingly to reflect the reset. ## API Access Load status updates can be submitted through the **Tour Actions API** as part of the advance action. The `loadStatusUpdates` field accepts an array of per-load status updates, each specifying the load ID, the new status, and optionally a failure reason and comment on a failure, or a deviation and a note on a success. Load statuses are included in webhook payloads for tour and shipment events, making them available to external integrations. Developers should consult the API Reference for detailed schema information and endpoint documentation. > **Load Status Tracking on Tours vs. Shipments:** Load statuses are tracked in two places, serving different purposes: > > * **On the Tour**: Each load carries a single, current status reflecting its state within that tour. This is what the driver and operators see and interact with. > * **On the Shipment**: Each load maintains a **status log** — a chronological history of all status changes across transport attempts. This provides a complete audit trail and supports shipments carried in stages, where a single shipment may be handled across multiple tours. See the [Legs](https://support.pr-4.orbit.do/en/multi-leg-logistics/legs-how-a-shipment-is-carried) article. > > When a load's status changes on a tour, the update is **automatically synchronised** to the corresponding Shipment's status log. > > ### Impact on Shipment Status > > A failed load does not automatically fail the whole shipment. Orbit works out the shipment's status from where each of its loads has actually got to. A shipment reads `Failed` when one of its loads has failed and nothing is carrying that load onward. > > So a load that fails on one stage of a journey, and is then picked up by a later stage, does not leave the shipment reading `Failed`. Neither does a load that has been moved onto a return shipment, nor one that has been put down at a hub and is waiting there. And retrying a failed stage clears it too: once the load is waiting to travel again, the shipment recovers on its own, with no status to reset by hand. > > A written off load is the one outcome that does not recover. Nothing is carrying it onward and nothing will, so the shipment closes as undeliverable. Loads on that same shipment that were delivered stay delivered. 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. > **Note:** Real World Example: > > A driver for Orion Logistics in Amsterdam arrives at a pickup stop with twelve pallets scheduled for loading. Using Orbit Cockpit, the driver initiates the departure and sees all twelve `Loads` listed in the status panel. Ten pallets are loaded successfully — the driver taps the success button for each. One pallet is damaged and another is missing from the warehouse floor. The driver marks these as failed, selecting "Load Damaged" and "Load Missing" as the reasons and adding a short comment. The dispatcher at Orion's office sees the two failures immediately in Orbit MissionControl, and the associated `Shipment` reads `Failed`, flagging it for follow-up. It stays that way until the dispatcher acts: retrying the collection for a fresh attempt, or moving the two pallets onto a return shipment. ## FAQ **Q: The goods were damaged but the receiver took them anyway. Delivered or failed?** Delivered, with a note. Mark the load successful and use **Complete with note** to record the deviation, a description and a photograph. Marking it `Not Unloaded` would say the goods never arrived, which would misstate what happened and would leave the `Shipment` waiting for a recovery it does not need. **Q: Can I update a load's status outside of the departure flow?** No. Load statuses are exclusively updated when departing from a stop, as this is the point where handling outcomes are operationally determined. **Q: A load failed. Is that the end of it?** No. An operator can retry the stage, which puts the load back to `Routed` for a fresh attempt, or move it onto a return shipment to bring it back. Cargo refused at its dropoff takes one step first, because it never left the vehicle: it is put down at a cross-dock hub and reads `Carried Back`, and the choices follow from there. 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. Where the goods will never travel again, they are written off instead of retried or returned. **Q: A refused load is showing at a stop it was not scheduled for. Why?** Because it is still on the vehicle and that stop is one of your cross-dock hubs, so it is somewhere the driver can put it down. It appears under its own heading, separate from the stop's scheduled work, and ticking it is optional: leave it if the driver is carrying it further. **Q: Are load statuses visible in webhooks?** Yes. Tour and shipment webhook payloads include the current load statuses and the full status log, respectively. **Q: Can I use the barcode scanner to update statuses outside of the departure flow?** The barcode scanner within the load status panel is available only during the departure flow. However, Orbit Cockpit also offers a standalone **Identify** function that allows scanning an Orbit-generated QR code at any time to view information about a load and its associated tour, without updating any statuses. **Q: What barcode formats are supported?** The scanner supports QR Code, Code 128, and Data Matrix formats. For the most reliable identification, we recommend using [Orbit Resource Numbers](https://support.pr-4.orbit.do/en/advanced-features/orbit-resource-number-orn) (ORNs) encoded as QR codes on your labels.