Design Merge Behavior for Offline Edits

Collaboration & Enterprise · offline, real-time, undo

Updated 2026-08-04

Expect edits made while disconnected to arrive out of order and long after they were made. A document edited on a plane merges into a document that has moved on, and the interface decides what that looks like.
Never resolve by discarding the older change. Deciding by arrival time means the person with the worse connection loses their work every time.
Merge at the smallest unit the content allows, which is what CRDTs are built to do. Two people editing different paragraphs is not a conflict, and treating the whole document as one value manufactures one.
Say what happened on reconnect. A summary of what synced, what merged, and what needs attention turns an invisible process into a visible one.
Design the operations that genuinely cannot merge and need a human:

Show what is not yet synced, per item. A single global indicator cannot tell the user which three of their forty changes are still pending.
Keep the offline queue durable and visible. Changes held only in memory are lost by a browser refresh, and the user believed they were saved.
Set an expectation about how long offline work is kept. Edits queued for two weeks may no longer apply, and the user should learn that before they rely on it.

Offline editing is a promise that work will not be lost, and the merge is where that promise is either kept or quietly broken.