Offline and sync
The mobile app is built for field work, where a network connection is unreliable or simply absent. Every form is saved on the device first and only reaches the server afterward — so the screens behave the same whether or not you have signal right now.
Who it's for
Every app user — driver and technician alike — since the offline mechanism is shared across every form: inspections, duty-status changes, fuel capture, messages, deliveries, and work-order actions.
Key concepts
- Action queue (outbox) — a local, ordered record of every change made offline, waiting to reach the server.
- Idempotency key — a unique id stamped on an action the moment it's saved; it's what stops a retried send after a connection drop mid-sync from creating a duplicate.
- Read cache — a local copy of reference data (vehicles, templates, the route, work orders) that lets a screen open with no network.
- Dead-lettered action — an action the server rejected after every retry was exhausted; it needs a manual look, since the app no longer retries it on its own.
Local database and read cache
Data a screen needs is read from the network first; a successful response refreshes the local copy right away, while a failed one (no network, or an error) makes the app fall back to the last saved copy and show that instead of an empty screen. The one exception is when the server explicitly answers that access has been withdrawn (say, you were removed from the organization) — in that case the app doesn't keep showing stale data "just in case"; it drops the local copy and asks you to sign in again. The same mechanism covers the vehicle list, inspection templates, the route of day, work orders, and the duty-status clocks.
The action queue and automatic sync
Every write — submitting an inspection, changing duty status, a delivery, a message, or a work-order action — goes into a local queue first, stamped with the organization it was created under. The app drains the queue automatically: right after the action is saved, on every launch, and on every network-recovery moment. An action that failed to reach the server for a network reason (no route, a timeout) goes back into the queue without using up a retry and tries again at the next opportunity. An action the server actually answered with a rejection — say, trying to move a work order past a step it isn't ready for — does use up a retry, and once retries are exhausted it lands among the dead-lettered actions instead of retrying forever.
Offline banner and the pending count
When the device loses connectivity, the app shows a banner flagging offline mode — every form stays fully usable, only the send is on hold. The top bar shows how many actions are still waiting to sync, so you always know how much work hasn't reached the server yet.
Actions that failed to sync
An action the server rejected after exhausting its retries drops out of the pending count and shows up on a separate "needs attention" banner — both on the dashboard and on the technician's work-order queue. The dead-letter screen shows the action's type and the error the server returned, and lets you requeue it with one tap once the reason for the rejection has been resolved.
Resetting local data
Switching the active organization refreshes every screen whose data depends on the organization (vehicles, routes, work orders, duty clocks), so you never end up seeing the previous organization's data by accident after a switch. Signing out goes further and clears all local device state — the action queue, the read cache, and any photos saved locally — which matters especially on a shared device, where a different driver signs in next on the same phone.