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.
More we can add to your workspace
- Conflicts are detected, not resolved. A conflict code tells you two changes collided; deciding the outcome is a human step.
- Truly offline payments. M-Pesa collection requires the network today, so a payment captured in the field is a record awaiting confirmation rather than a completed transaction.
- Queued eTIMS transmission during an outage. Fiscalisation happens at sync today, which is what makes a long outage a compliance question and not only an operational one.
- An offline card or mobile-money authorisation.
- Offline counting and offline 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 needs a connection to take a sale. Both are commonly assumed from the presence of offline capture elsewhere, so correct the assumption before go-live rather than after.
- Offline job cards and job time. Evidence attached to a job needs a connection today, 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.
Anything above that you need, we can build for you
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point, not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for whatever you just read about. One qualification so this is worth what it claims: a small number of things on this blog we deliberately leave to a specialist rather than build — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped additions, which are the ones readers ask for most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsRun 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.
