Insight · ·

Offline first means deciding who wins

Saving locally is only the beginning. An offline field app needs explicit rules for conflicting edits, revoked access and work that has not reached the server.

Offline first means deciding who wins

The form saved, but whose version survived?

A field technician edits an inspection while disconnected. A coordinator changes the same assignment in the office. When the device reconnects, both changes are legitimate, but they cannot necessarily coexist. Silently keeping whichever arrives last is a product decision disguised as a synchronisation implementation.

Offline support starts with that decision. A cached screen proves that the interface can open. It does not prove that a person can complete useful work, understand what remains on the device, or recover when the organisation has changed the record meanwhile. We would define those promises before selecting a storage library.

Separate working locally from being accepted centrally

The interface needs distinct states for a local draft, pending submission, server acceptance and a conflict requiring attention. The word saved is ambiguous if it covers all of them. A technician leaving a site should know whether the evidence is safely on the device or already available to colleagues.

Browser background synchronisation can help resume short tasks when connectivity returns, but browsers restrict background work and retries. It is not a promise that every queued change will eventually arrive without the app being revisited. MDN's offline operation guide explains these limits.

Provide a visible pending-work view and a foreground retry route as well. A stalled upload needs a meaningful explanation, not an indefinitely spinning icon. Preserve the original local work until its acceptance or deliberate removal is confirmed. Otherwise an apparently tidy queue can conceal lost evidence.

Choose conflict rules by the meaning of the field

In an illustrative inspection product, adding a photograph and changing an assignment are different operations. Photographs can usually be appended with provenance. An assignment change may invalidate who is allowed to submit the inspection. Treating both as replacement of the entire record loses that distinction.

For editable fields, retain the server revision on which the local change was based. If it has changed, identify whether the edits touch independent information or compete for the same decision. Independent notes may be combined. Contradictory completion states may need review. Device timestamps alone should not decide who is right.

A conflict screen should show the relevant differences, authorship and the consequences of each choice. Asking an operator to choose between entire raw documents is technically honest but operationally weak. Resolution belongs at the level of the work people recognise.

Permissions and deletion still apply while disconnected

An offline copy can outlive the permission that originally allowed its download. Define what may be stored locally, how shared devices are handled and what happens at sign-out. Do not imply that a remote revocation can instantly erase a disconnected device. Limit the local dataset according to the sensitivity of the work.

Recheck authority when pending changes reach the server. A valid local draft does not automatically remain an authorised submission. If access has changed, preserve a recoverable explanation and route the case appropriately instead of silently discarding it or accepting it through an old session.

Deletion also needs a rule. A removed server record should not reappear because a device submits an older copy. Represent the intent to delete or retire a record in the synchronisation model, and decide what happens to local evidence attached to it.

Rehearse reconnection this week

Choose a real field task and simulate disconnected editing while someone changes the same record centrally. Reconnect after changing permissions, then repeat with an interrupted attachment upload. Review what both people see, not just the server logs.

Write the rule for every conflict encountered. Make pending work visible and provide a clear resolution owner. If the team cannot explain which version survives and why, the feature is not ready to promise reliable offline work, even when every screen loads without a network.