How Do You Merge Two Users’ Changes in an Offline Field App?

Short answer

When two people change the same record in an offline field app, “last writer wins” is not suitable for every task. Consider the record version, changed fields and business criticality. Show unresolved conflicts to the user or authorised operations team, rather than hiding data loss behind a success message.

Technical merging and business decisions are different

Two users changing different note fields is not the same as changing the same stock quantity. Free text, status transitions, inventory and approval fields need separate rules. Track the last known record version and which fields each user changed. Resending the entire record to overwrite older fields can cause data loss.

A field work order may be closed while another device edits its old record offline. The server must not accept that action solely because it arrives later. Check current business state and user permissions. Device time alone is not a reliable transaction order; distinguish local creation time from server acceptance time.

Show the user three states

Saved locally, transferred to the server and awaiting conflict resolution are distinct states. Offline users may understand “record completed” as approval of the entire job. Explain where the record is stored and which step is pending. Show relevant fields from both versions and the responsible person when a conflict occurs.

A product such as Firestore supporting offline access does not mean it automatically resolves application business conflicts correctly. Match documented synchronisation behaviour with company inventory, approval and work-order rules. Link file-upload and record queues too; define the state of a record missing its photograph.

A repeatable two-device test

Open the same record on two devices and disconnect them. Change job status on one and description on the other, then reconnect in reverse order. Also test changes to the same field, cancelled work and users with revoked access. The expected result is not just finished synchronisation, but visibility of which version was accepted and why. Return unresolved records to the processing queue.

Implementation checklist

Does every critical field have a conflict rule?
Is the record version sent?
Are local saving and server acceptance distinguished?
Are permissions and current business state checked?
Is there a two-device test with reverse connection order?

Frequently asked questions

Is last writer wins sufficient?

It may be chosen for notes; business decisions such as inventory or approval need separate evaluation.

Does device time prove transaction order?

Not by itself. Address incorrect clocks and delayed transfers separately.

Scope and limitations

Synchronisation rules depend on data type, provider and organisational workflow. Define device security and retention policies separately for personal data stored offline.

Sources and currency

Source review: 7 October 2026. Linked document versions and provider terms may change. Check the current version of the relevant source before implementation.