--- 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-5.orbit.do/en/core-features/load-status-tracking" locale: "en" apps: ["cockpit", "mission", "connect"] lastReviewed: "2026-10-28" --- # 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, unless your organisation [counts pickups as loaded](#counting-pickups-as-loaded). 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 > > **A photograph of every deviation**: A failed load and a load completed with a deviation can carry a photograph, and your organisation can make that photograph mandatory ## 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. | | **Dropped** | 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-5.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 dropped rather than retried or returned. A drop is recorded against the single `Load` it concerns, and creates no onward movement of its own. See the [Dropping Goods That Cannot Be Delivered](https://support.pr-5.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. | | **Nobody was there** | Nobody was there to hand over or take the goods. | | **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 and, in Orbit Cockpit, take a photograph of the load. 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 independent: a note can be left without a deviation, and a deviation without a note. They are optional unless your organisation requires a photograph for every deviation, see [Photo Policies](#photo-policies). 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 * at the delivery stop in Orbit Cockpit, as a line under the load on the stop's load list, in the load status panel and in the load's details, so the delivering driver sees a difference recorded at loading before handing the goods over. A `Shipment` carried in several `Legs` shows every loading on its current route in order, the shipper's pickup first and then each reload at a cross-dock hub. The driver of the next `Tour`, who takes the load over at a cross-dock hub, sees the same line in the same three places at that pickup stop, with the notes of the earlier loadings and not the one recorded at that stop. At the shipper's pickup there is no earlier loading, so no line appears there. When a load was loaded with a note more than once on its way, each of those loadings has its own line, in route order. The line stays when the delivery fails, and a note the driver adds on delivery is kept as a record of its own. Where the stop asks for a `Documented Signature`, the Signing Summary shows the recipient the same lines, and the delivery or collection receipt prints them in the load's row: see [Documented Signatures & Delivery Receipts](https://support.pr-5.orbit.do/en/advanced-features/documented-signatures-and-delivery-receipts) * in the review of the `Tour` in Orbit MissionControl, where the **Loads** figure counts them and the **Findings** list names them under **For Information**, so a tour carrying one is easy to spot without holding up its review. A load handed over with damaged goods or packaging is also named under **Check** * 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, its comment and the photograph do that job, and a note sent with a failure is ignored. ### Photographs of a Load A photograph taken in the failure modal or in **Complete with note** attaches to that individual `Load` at that stop, which is what distinguishes it from the handover photographs taken during a signing ceremony. It is also one of the stop's proofs, so it counts towards a **Photo** the stop or the `Shipment` requires. If a photograph cannot be uploaded, Orbit Cockpit keeps it visible in the modal and offers a retry. When the link was not sent, retry uses the stored photo, so the driver does not need to take it again. If the photo still cannot be linked, the driver can take it again. Where the photograph is optional, confirming while a photo has failed asks the driver to retry or continue without the photo. ## 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: * Two lines: the count, the type and the description, for example **4 × Euro pallet · Printed matter**, and below it the reference or, for a load without one, its dimensions and weight * The notes recorded when the load was loaded earlier on its way, where there are any * Two buttons: **×** to mark the load as **failed**, and **Unloaded** or **Loaded** to mark it as **successfully handled** A tap on the row opens the load's details, with its dimensions, weight, reference and route and the status the driver has marked so far. **Marking a load as successful** sets the status to `Loaded` (at a pickup stop) or `Unloaded` (at a dropoff stop). A line with a pencil then appears under the load: **Add a note (optional)**. Where the load changed hands with a difference worth recording, it opens **Complete with note**, which adds a deviation, a note and a photograph to that successful outcome without failing it. Once a note is saved, the line shows it. **Marking a load as failed** opens a modal where the driver can optionally select a failure reason, add a comment and add a photograph with **Add photo**. The status is set to `Not Loaded` (at a pickup stop) or `Not Unloaded` (at a dropoff stop). The line under the load then shows the reason, or the comment without one, in red. A tap on it opens the modal again to change them. When a `Shipment` has more than one load at the stop, the details of each of its loads offer **All 3 loads not unloaded**, or **All 3 loads not loaded** at a pickup stop. The button opens the same modal for every load of that shipment at once. A photograph taken there documents every one of those loads: Orbit Cockpit stores it once for each load, so each load carries its own copy. 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 in the panel before the departure can proceed. Where your organisation counts pickups as loaded, the panel leaves those pickups out, see [Counting Pickups as Loaded](#counting-pickups-as-loaded). #### 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-5.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, so a load failed or completed with a note here has none. 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. ### Counting Pickups as Loaded Where the warehouse loads the vehicle, the driver has nothing to confirm at the pickup. For such operations, the loads at a pickup stop can be counted as `Loaded` without the driver confirming them in Orbit Cockpit. 1. In Orbit MissionControl, open **Settings** and select **Review**. 2. On the **Loading at Pickup** card, turn on **Count pickups as loaded**. 3. Select **Save**. Changing the setting requires permission to edit the company profile; without it, the card shows the current value and cannot be changed. Turn the switch off and save to have drivers confirm every load again. A pickup load is counted as loaded only when its `Shipment` requires no **Scan** at that stop. Dropoffs are always confirmed by the driver. With the setting on, Orbit Cockpit behaves as follows when the driver departs: | Stop | What the driver sees | | --------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | Only pickups, none requiring a **Scan** | No load status panel opens. The departure records every load at the stop as `Loaded`. | | Pickups and dropoffs | The panel lists only the dropoffs. When the driver confirms them, the same departure records the pickups as `Loaded`. | | A `Shipment` requires a **Scan** | Its loads stay in the panel with the scanner, as without the setting. The other pickups at the stop are still counted as loaded. | At one of your cross-dock hubs, cargo refused earlier on the tour still opens the panel, as described in [Cargo carried from an earlier stop](#cargo-carried-from-an-earlier-stop). Where the stop asks for a `Documented Signature`, the Signing Summary shows the counted pickups as loaded. With [automatic stop detection](https://support.pr-5.orbit.do/en/core-features/stops-arrival-tracking#arrival-and-departure-in-orbit-cockpit) enabled, the counted pickups are never reported as missing. At a stop with only such pickups, Orbit Cockpit records the departure on its own when the driver leaves, with every load `Loaded`. At a stop with dropoffs, the departure still waits until the driver has confirmed them. Because no driver confirms the counted pickups, the driver cannot mark one of them as `Not Loaded` or add a note to it at the pickup. A load that was not loaded after all is marked at its dropoff, as `Not Unloaded` with the reason **Load Missing**, or corrected by an operator in Orbit MissionControl, for example by reverting the departure as described in [Reverting a single advance](#reverting-a-single-advance). The setting changes only what Orbit Cockpit asks of the driver. A departure confirmed in Orbit Connect or Orbit MissionControl still lists every load. ## Photo Policies Your organisation decides whether a driver must take a photograph. Two settings do this, independently of each other. Each is either optional or mandatory, and a setting nobody has chosen reads as optional. | Setting | When it applies | When it is mandatory | | -------------------------- | -------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | `loadDeviationPhotoPolicy` | A load marked as failed, with any reason or none, and a load completed with a deviation such as **Accepted damaged** | Orbit Cockpit asks for a photograph of the load before the driver can confirm the deviation and before the stop can be left | | `scanExceptionPhotoPolicy` | A load the driver confirms by hand with **Confirm Manually** instead of scanning it | **Confirm Manually** stays unavailable until a photograph has reached Orbit | While both are optional, Orbit Cockpit offers **Add photo** and the driver decides. ### When photographs of deviations are mandatory * **Confirm** in the failure modal stays unavailable until a photograph of the load counts, whatever the reason. In **Complete with note** the same holds once a deviation is chosen; a note without a deviation needs no photograph. **Photo required** under **Add photo** says why. For a whole shipment, the one photograph taken in the modal serves every load. * **Confirm without photo** is not offered. * The stop cannot be left while a load the driver marked there has a deviation without a photograph. A line above the confirm button of the load status panel names how many deviations lack one, and a tap on it opens the first of them, where the driver can retry the upload or take the photograph again. * A photograph counts from the moment it is taken, while it uploads. It stops counting when its upload fails or is cancelled, for example without a mobile connection, and the stop is held again until the driver retries or takes it again. Once the driver has left the stop, a photograph that fails afterwards does not hold the driver back, and Orbit never refuses a departure for a missing photograph. A load failed or completed with a note in Orbit Connect, in Orbit MissionControl or through the API carries no photograph either. The review catches these cases: with automatic tour completion, the exception **Deviation Photos Are Missing** is active by default under a mandatory photograph and keeps such a tour in review, and the review's **Findings** list names "1 deviation without photo" at the stop. See [Automatic Tour Completion](https://support.pr-5.orbit.do/en/advanced-features/automatic-tour-completion) and [Reviewing a Tour](https://support.pr-5.orbit.do/en/core-features/tour-review). ### Setting the policies Orbit MissionControl has no screen for these two settings. `GET /v5/tenant` reads them, and `PATCH /v5/tenant` sets either or both: a setting left out keeps its value. You can also ask Luna, or an AI assistant connected over MCP, to read or change them. A change needs the permission to change your company settings, which the admin role has by default; an API key needs a role with that permission. Orbit agents that work on their own, without a person, cannot change them. ## 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 and the note. Photographs of a load appear among the stop's proofs, and in the review of the `Tour` in Orbit MissionControl under the failed or noted load they document. In Orbit Cockpit, a completed stop marks each load with a green check or a red cross and shows the reason or the deviation as a badge under it. A tap on the load opens its details, with the full comment. * **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. The shipment timeline also groups a `Leg`'s `Load` outcomes into its attempt row. Its load count includes only the `Loads` on that `Shipment`, so other `Shipments` carried on the same `Tour` do not change the quantity shown. ## 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-5.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 dropped 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 dropped 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 make a photograph mandatory for every failed load?** Yes. Set `loadDeviationPhotoPolicy` to mandatory, through the API or by asking Luna. Orbit Cockpit then asks for a photograph of every failed load and of every load completed with a deviation, before the driver can confirm it and before the stop can be left. See [Photo Policies](#photo-policies). **Q: The driver took the photograph but cannot leave the stop. Why?** Its upload failed, so it no longer counts. The line above the confirm button names the deviations that lack a photograph; a tap on it opens the first one, where the driver can retry the upload once there is a connection or take the photograph again. **Q: Can drivers skip the loading confirmation at a pickup?** Yes. In Orbit MissionControl, turn on **Count pickups as loaded** under **Settings** → **Review**. The loads at a pickup are then recorded as `Loaded` when the driver departs. Loads whose `Shipment` requires a **Scan** at the stop are still scanned and confirmed by the driver. See [Counting Pickups as Loaded](#counting-pickups-as-loaded). **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-5.orbit.do/en/multi-leg-logistics/when-a-delivery-fails-what-to-do-next) article. Where the goods will never travel again, they are dropped 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-5.orbit.do/en/advanced-features/orbit-resource-number-orn) (ORNs) encoded as QR codes on your labels.