Offline-First Field Workflows: If the App Needs Signal, the Field Uses Paper
If the app needs signal, the field will use paper — what offline-first actually means, which workflows must survive airplane mode, and how sync conflicts get resolved without losing the truth.
Every field software demo happens in a boardroom with WiFi. Every field software failure happens in a basement in Kitui with one bar of 2G. The gap between those two rooms is the single most important technical property of field operations software: offline-first means the system is fully functional with no connectivity at all, and treats the network as a bonus — not a dependency. Anything less produces the most expensive outcome in field IT: a system the office believes in and the field quietly routes around.
What must work in airplane mode
The airplane-mode test — run it before you buy
- Open the day's jobs and routes, with customer details and materials lists.
- Record a delivery or job completion — photos, GPS point, signature.
- Issue stock from the van; record a van sale with cash or M-Pesa reference.
- Perform an asset check with condition notes and a photo.
- Raise a requisition or incident report from the field.
- Close the visit — and see it queued, clearly marked as awaiting sync.
GPS deserves a special note: location capture works without data (the satellites don't care about your bundle), so a well-built app stamps coordinates offline and reconciles the map when it syncs. "No network" is never a reason a visit has no location.
Sync: where offline systems earn their keep
- Queue transparency. The field user sees exactly what is captured-but-unsent; nothing vanishes into a spinner. Anxiety about "did it save?" is what drives duplicate entries and paper backups.
- Order preservation. A morning issue and an afternoon return sync in sequence even if the phone reconnects at 9pm — timestamps come from capture time, not sync time.
- Conflict resolution with a rule. Two users touch the same record offline; the system applies a declared rule (field evidence usually wins on field facts; office wins on master data) and flags the collision for review instead of silently overwriting either side.
- Partial sync tolerance. Ten minutes of hotspot at a petrol station should push the day's critical records first — evidence and money before photos at full resolution.
The paper fallback is a symptom
When a field team keeps a notebook "just in case", they are telling you the system fails the airplane-mode test — or fails the speed test at the customer's gate. Fix the workflow; don't laminate the notebook. Every parallel record is a future reconciliation dispute.
Designing field workflows that survive reality
- Two-minute capture. A delivery record at the customer's gate must take less time than the goodbye — prefill everything the office already knows, capture only what the field uniquely sees.
- Evidence over narration. A photo and a GPS point beat three paragraphs; structured reasons beat free text — the same principle that makes stock adjustments auditable.
- Battery and data as real constraints. Daylight-readable screens, low-data photo compression, and end-of-day charging habits are operational planning, not IT trivia.
- The nightly heartbeat. Whatever the day held, the evening ritual is: sync, review the queue is empty, count the van. Three checks, five minutes, and the reconciliation starts from truth.
Offline capability is the foundation the whole field operations stack stands on — van stock, job evidence, custody, and fleet data all inherit their reliability from it. Where AWRA sits on that spectrum is worth stating precisely rather than with a label: the mobile app queues four operations with no connection — stock transfers, inventory check-out and check-in, and asset movements. Counting, receiving against a purchase order, dispatch and selling all need a connection. That is offline-tolerant for stock movement rather than offline-first across the board, and the honest description is the four operations rather than either adjective.
What AWRA OpsHub does today
- A registered offline device per user, with an operation queue holding module, action, entity type and entity id.
- Queued operations replayed on reconnect, with sync attempts tracked so a failure is visible rather than silent.
- Conflict codes and messages recorded on an operation, so a clash is surfaced rather than quietly overwritten.
- Four operations captured offline and reconciled at sync — stock transfers, inventory check-out and check-in, and asset movements.
What it does not do
- Conflicts are detected, not resolved. A conflict code tells you two changes collided; deciding the outcome is a human step.
- Payments are not truly offline. M-Pesa collection requires the network, so a payment captured in the field is a record awaiting confirmation, not a completed transaction.
- eTIMS cannot transmit while offline. Fiscalisation happens at sync, which makes a long outage a compliance question and not only an operational one.
- No offline card or mobile-money authorisation.
- Counting is not offline, and neither is selling. A stock count has to agree with a shared current state rather than simply recording what is in somebody's hands, and a till with no connection cannot take a sale. Both are commonly assumed from the presence of offline capture elsewhere, so correct the assumption before go-live rather than after.
- Job cards and job time are not offline. Evidence attached to a job needs a connection, so a crew working a genuine dead zone captures stock movement on the spot and the job record on return.
The architecture here is genuinely strong and it is one of the few places where a Kenyan field reality was designed for rather than apologised about. The honest boundary is money and fiscalisation: data survives an outage well, payment and tax transmission do not.
Run the airplane-mode test on us
Stock transfers, check-out, check-in and asset movements captured with the network off, queued, and reconciled with conflict codes at sync — and a straight answer about everything that is not on that list.
See offline workflows in AWRAFrequently asked questions
How long can a device stay offline before data is at risk?
Days, not hours — capture is stored locally until synced, so a crew on a three-day rural circuit loses nothing. The practical limits are device storage (photos) and the business's tolerance for delayed visibility, which is why the nightly-sync ritual matters even when the system doesn't force it.
What happens if the phone is lost or damaged before syncing?
Unsynced local data on that device is the exposure — which is why the ritual is sync-at-every-opportunity, not sync-at-day-end-only. Mitigations: opportunistic background sync whenever signal appears, critical records prioritized, and device PINs so a lost phone is a data loss, not a data breach.
Do offline apps drain batteries faster?
Generally the opposite — an offline-first app isn't burning radio power retrying a weak connection all day. The real battery costs are screen time and GPS sampling frequency, both tunable. A field day on one charge is a reasonable expectation on ordinary hardware.
How do we trust GPS stamps — can they be faked?
Location spoofing exists, which is why evidence is layered: GPS plus timestamped photos plus customer sign-off plus the stock movement itself. Falsifying all four consistently is dramatically harder than forging a paper delivery note ever was — the bar isn't perfection, it is being categorically better than what it replaces.
