Offline-First Field Software: A Decision Protocol for Reliable Operations

Define offline-first as an operational capability

Offline operation means more than reopening a cached screen. Field teams must know which tasks remain available, how current the data is, and which actions still await server confirmation. That distinction prevents a false success state.

Android's offline-first guidance places a local source ahead of the upper application layers. The network refreshes and reconciles that source, but each read does not depend on a remote call. For Atlas, local work must be explicit, durable on the device, and observable until the server accepts it.

Choose a strategy for each type of write

Not every write can follow the same rule. A note or photo may wait locally, while a stock issue, price approval, or collection changes shared state and requires stronger control. Classify the action before choosing the technology.

Write the synchronisation contract before the screens

Every local operation must be replayable after an outage without producing a second business effect. The device creates a stable operation ID before sending; the server stores that ID with the result and returns the same result when the request is repeated. This complements HTTP idempotency semantics.

The contract also carries the entity ID, base version, author, captured time, received time, and action type. At minimum, local status distinguishes queued, processing, accepted, and correction required. A business rejection is not a network failure.

• Create the operation ID on the device and retain it after restart.
• Include a base version to detect concurrent changes.
• Store the server response with the resulting version.
• Retry technical failures with progressive backoff.
• Use a separate exception queue for business rejections requiring human action.

Resolve conflicts according to business meaning

Last-write-wins is simple to code but dangerous when it erases evidence, changes an assignment, or hides a stock movement. Resolution must depend on the data type and leave an auditable trace.

Run an outage acceptance test, not a desk demo

The decisive test uses real devices, data volumes, and field journeys. Cut the network at the wrong moment, stop the application during a write, and create a concurrent change from another device. Prove what the user sees and what the system receives, not merely that the queue eventually empties.

• Create several operations in airplane mode, close the app, restart, and synchronise.
• Repeat the same action and verify that only one business effect occurs.
• Edit the same record on two devices and verify the declared conflict rule.
• Remove a user's right during the outage and verify controlled rejection on reconnection.
• Test a device with the wrong time; never treat its clock as an absolute order.
• Measure queue age, rejection rate, conflicts, recovery time, and blocked operations.

Make a Go, Conditional Go, or No-Go decision