Offline sync: how a field app works without signal

Why offline-first, and not just a mobile website?

A responsive website needs a live connection to do anything useful. Field work happens where the connection is not: basements, plant rooms, rural notspots, and multi-storey car parks. An offline-first native app is architecturally different. It keeps a working copy of the data on the device, so the engineer can view the day, complete a job, capture evidence, and take a payment with no signal at all. The platform catches up when the connection returns.

This is a core part of how we build React Native apps for frontline and field teams. It is the capability a web CRM in a mobile wrapper cannot match, because a browser tab has nothing to fall back to when the network drops.

How offline sync works, in plain English

The design has four moving parts. None of them is exotic, but they have to be got right together.

• On-device store. The app holds the data it needs (the day plan, job detail, pricing, history) in local storage, and reads and writes there first. The interface stays fast and fully usable offline because it is never waiting on the network.
• Queue-and-forward. Every action the engineer takes (accept a job, take a photo, capture a signature, take a payment, complete a visit) is written to a local queue as a discrete, ordered operation. The queue is the record of intent, and it survives the app being closed or the phone being restarted.
• Idempotent sync. When a connection returns, the queue drains to the server. Each operation carries an idempotency key, so if a sync is retried after a flaky connection, the server recognises the operation it already applied and returns the same result rather than applying it twice.
• Conflict resolution. Where the server state has moved on since the device last synced, changes are reconciled field by field against an explicit precedence rule, not a blanket overwrite. Independent changes merge; genuine conflicts resolve to a defined winner; ambiguous cases are surfaced rather than buried.

How it behaves at the edges

Offline sync is entirely about the edges. A demo on office wifi proves nothing; these are the cases that decide whether the design holds.

• Two engineers accept the same job offline. Both accepts queue and are resolved on reconnect. Ownership is a serialised, per-record decision on the server, the same concurrency pattern proven in the Booking Engine’s checkout reservations, so exactly one engineer ends up owning the job and the other’s plan corrects itself. There is no phantom double-booking to unpick later.
• A payment succeeds but the sync fails. The payment is confirmed with the provider and recorded locally with an idempotency key at the point of sale, so it is never lost with the failed sync. On reconnect it reconciles exactly once, and a replayed sync returns the existing result rather than a second charge.
• Conflicting edits to the same job. A central reassignment or cancellation made at head office takes precedence over a stale local edit, while independent fields (a note here, a photo there) merge. The precedence is defined per field, so the result is predictable rather than a race.
• A job cancelled centrally while being worked offline. The completed work and its evidence still sync and are retained against the record, so an engineer’s effort is never discarded; the cancellation and the completion are both visible, and the conflict is flagged for the office to settle.
• Clock skew between device and server. Ordering relies on server-assigned sequence and the operation queue, not solely on device timestamps, so a phone with the wrong time cannot reorder history or win a conflict it should have lost.
• The app is reinstalled mid-queue. Because queued operations are persisted and carry idempotency keys, a recovered or reinstalled device does not replay work that already reached the server, and anything genuinely unsent is preserved to sync.

Integration points

Offline sync is the substrate the other field capabilities rely on.

• Job allocation uses the server-side serialised concurrency described in job scheduling and routing.
• Payments reconcile through the idempotent transitions of the Billing Engine, covered in quotes and doorstep payments.
• Evidence queued offline follows the same upload-on-reconnect path described in job evidence and compliance.

Why it matters

Offline is not an edge case for field work; it is most of the day. An app that loses a payment, double-books a job, or silently overwrites an engineer’s edit when the signal returns is worse than no app, because it erodes the trust that made people use it. Getting sync right, idempotent, ordered, and conflict-aware, is what lets a field team rely on the app in the places the network cannot reach. For the wider requirements this sits inside, see what a franchisee field app should actually do.