An offline-first field app should tell a worker whether their changes are saved on the device, accepted by the server or waiting for a decision. Those states are different. Build the sync plan around the records people must preserve, the changes that may conflict and the actions that need a live connection.
This guide follows a fictional room-measurement job completed by two surveyors. It shows how to specify offline behavior before commissioning a mobile or PWA build. The conflict scenario is illustrative; the separately linked FloorPlanz Pro case study provides authentic context for a drawing-to-installer-document workflow.
Key takeaways
- Choose offline behavior per task rather than promising that every feature works without a connection.
- Persist unfinished work and make its sync state visible.
- Resolve important measurement conflicts through an explicit business rule.
- Test interrupted uploads, app restarts and incompatible edits on target devices.
Agree what a worker can complete without a connection
For the measurement job, the surveyor needs the assigned rooms, existing dimensions, relevant notes and the ability to record new measurements. They may also need to take photographs and prepare a local draft. The office still owns the final approval for the installation document.
Separate reading, recording and committing a shared decision. Viewing yesterday's room list offline can be acceptable if its age is visible. Recording a new measurement can be useful without the server. Reserving scarce stock or confirming a shared schedule may require a current server decision. Label those actions accordingly.
Ask the team to write an offline scope sheet before choosing a framework. Include what must be downloaded ahead of a site visit, how stale information is presented and what the worker sees when the necessary data was never downloaded. A loading spinner is not a complete offline experience.
Give local work a durable home and a visible state
Android's offline-first architecture guidance separates persistent local data from network data and explains queues, retries and conflict resolution. For our example, the screen reads the locally available job while a separate sync process exchanges changes with the server. The exact tools depend on your platform.
The product requirement is simple to state: a measurement saved before an ordinary app restart must still be present afterward. A queued update also needs a stable identity so reconnecting does not create another copy of the same intended change. Keep the data and the pending-operation record consistent.
Use messages that describe what has actually happened. 'Saved on this device' is appropriate before upload. 'Synced' needs server acknowledgment. If the office must approve the result, show that as another state. Do not replace these distinctions with one reassuring green checkmark.
| State | What the worker can rely on | Next step |
|---|---|---|
| Local draft saved | The measurement is persisted on this device. | Keep it available while waiting for connection. |
| Waiting to sync | The change is queued; the office may not have it. | Retry when eligible and show outstanding work. |
| Server accepted | The server acknowledged this operation. | Show the accepted revision and any pending approval. |
| Conflicting measurement | Another revision exists; neither value has been silently chosen. | Send the competing values to the agreed review path. |
| Approved for installation | The designated reviewer approved the specified revision. | Generate or publish the installation document from that revision. |
Work through two surveyors changing the same room
Both surveyors download room revision 12. While offline, one records a width of 4.20 meters and the other records 4.35 meters. These are fictional inputs. On reconnect, the server can detect that both changes were based on the same earlier revision. The difference affects the installation output, so silently keeping whichever upload arrives last is a poor rule for this example.
Retain both proposed measurements, their authors and the revision they started from. Put the room into a visible review state and allow the designated reviewer to choose or request a new measurement. Keep the installation output tied to the approved revision. The surveyors should see why their local draft differs from the accepted result.
Other data may need another rule. Two photographs can usually be retained as separate records. An append-only site note can preserve both observations. A shared room dimension needs a considered decision. Choose at the field or business-record boundary rather than applying one conflict rule to the entire app.
What must your field team preserve without a connection?
Share the site workflow, target devices and approval rules. We can define local save, sync and conflict behavior for a representative pilot.
Keep a missing photograph from looking like a finished job
Record data and attachments can reach the server at different times. In this example, the dimensions arrive while a large photograph is still waiting to upload. The server can acknowledge the measurement, but the job should not appear evidence-complete if that photograph is required.
Track each attachment using its own reference and transfer state. Preserve the local source until the expected server result is verified, subject to the product's storage and retention policy. Show the worker which item failed and whether a retry will help. If device space runs out, explain what can be removed safely instead of discarding unsynced evidence.
Also define reassignment and sign-out behavior. A queued job may belong to a previous account or to a worker whose permission changed while offline. Verify authorization again when the operation reaches the server. Decide how the worker can recover their local work without bypassing the new access decision.
Plan sync timing around the actual working day
Consider first download, short site visits, long disconnected periods and the end-of-shift handover. A surveyor who leaves the depot before the initial download completes has a different problem from one whose measurements are waiting to upload. Make both states visible.
Microsoft's Field Service documentation provides a concrete example of configurable synchronization frequency and user settings such as Wi-Fi-only syncing. Those are Dynamics capabilities, not automatic features of your custom app. They illustrate why timing, data allowance and worker controls belong in the requirements.
For a custom app, define the expected foreground and background behavior on each target platform and verify it on actual devices. Do not promise immediate background upload simply because a desktop browser test worked. Give the user a reliable way to open the app, review outstanding work and initiate an eligible sync.
Commission an acceptance demonstration, not an offline checkbox
Provide a representative job with synthetic data and agree what successful behavior looks like. Download it, disconnect, change a measurement, add a photograph and restart the app. Then reconnect under a slow or interrupted connection. Verify the persisted local record, the accepted server result and the remaining upload states.
Repeat with a second device editing the same dimension. Exercise a rejected change, changed permissions and an app update while work is queued. Keep the outcomes visible to both the worker and office reviewer. The goal is to explain where every consequential piece of work ended up.
MUBBITS' FloorPlanz Pro story demonstrates an actual planning product and installer-ready outputs. It does not establish that the fictional conflict model here is implemented in that product. Bring your own field workflow, device constraints and approval rules when scoping a connected app; those details determine the sync work and its acceptance criteria.
An offline field-app acceptance brief
Use when asking a development team to scope a pilot.
Our workers must complete [tasks] during [disconnected conditions] using [devices]. They need [downloaded records] and can create [measurements, notes, files]. Specify local save, upload and approval states. Demonstrate restart persistence, repeated delivery, interrupted attachment upload, two-device conflicts and changed permissions. Identify actions that require a connection and provide evidence from the target devices.Frequently asked questions
Does offline-first mean the whole product works offline?
No. Specify the tasks and records that remain useful without a connection. Some actions need current server information or authorization and should show that requirement clearly.
Is last-write-wins a good rule for measurements?
It may discard a meaningful conflicting edit. In the fictional room example, the measurement affects installation, so competing values go to review. Choose a rule from the consequence of the data, not merely implementation convenience.
Can a PWA meet these requirements?
Evaluate the required persistence, device integration, background behavior and deployment constraints on the actual browsers and devices. The delivery format alone does not prove that unsynced work survives or that conflicts are handled correctly.
Let’s work through your next step.
Tell us what you’re building, what you’ve tried, and where you need a hand. We’ll work with you to define a practical way forward.