Load Status Tracking

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.

Load Status Lifecycle

A load progresses through a defined set of statuses as it moves through the transport process:

Status Flow

The status of a load follows a strict progression:

                   ┌─── Loaded ───┬─── Unloaded
                   │              │
Routed ────────────┤              └─── Not Unloaded
                   │
                   └─── 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 are terminal states — a load that failed at one stage cannot progress further on the same tour.

Failure Reasons

When a load is marked as Not Loaded or Not Unloaded, the driver can optionally provide a reason:

In addition to selecting a predefined reason, the driver can enter a free-text comment to provide further context.

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).

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.

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.

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)

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.

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.

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.

• 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.

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.

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.

FAQ