Field users lose signal in the middle of a task. The app still has to work. Then it has to catch up without losing a record.
We faced this in a real-estate CRM app that handles 100K+ leads a month. The rebuild made it about 30% faster.
Our take
Three places hold the truth:
- a local store on the phone
- an outgoing sync queue
- the server
The UI updates optimistically from the local store. When the network is back, each queued change reconciles or rolls back. The server has the final word.
That works well for one user on one device.
Where it hurts
Two people edit the same record while both are offline.
Both changes reach the server later. One of them has to lose, or the two have to merge.
Options we weighed:
- last write wins. Simple, but it silently drops someone's work.
- field-level merge. Fairer, but you need to track changes per field.
- ask the user. Safest, but it interrupts the flow.
Your turn
Two offline edits collide. Who wins in your app, and how do users find out?
Top comments (1)
My vote goes to field-level merge as the default, with "ask the user" kept for one case only: two people changed the same field to different values.
The reasoning: in a CRM, most collisions are not real conflicts. One person updates the phone number while another changes the status. Last write wins throws one of those away for no reason, and nobody notices until a lead goes cold.
For telling users, I would avoid a blocking dialog. A small note on the record ("status changed by Sara while you were offline") plus a per-field history is usually enough, and it keeps field staff moving.
The last write wins is fine for one thing: fields where only the latest value matters, such as "last contacted." How do you track per-field changes on the phone, a timestamp per field, or a change log?