Design the Moment a Save Is Rejected

Collaboration & Enterprise · real-time, errors, undo

Updated 2026-08-04

Decide up front whether the product uses pessimistic locking to block a second editor or optimistic locking to let both edit and resolve afterwards. Locking prevents the conflict and frustrates people, and allowing it means designing the rejection.
Show that someone else is in here before the conflict happens. A presence indicator on the record prevents most collisions at zero cost.
Never let a later save silently overwrite an earlier one. The second person wins, the first person's work vanishes without a trace, and neither of them finds out.
Design the rejection as a resolvable state rather than an error. This was changed by Alex while you were editing with both versions visible is a decision, and Save failed is a dead end.
Keep the rejected edit intact and editable. The user must be able to see their version, see the current one, and choose without retyping.
Offer the three resolutions explicitly:

Scope the conflict to the field where possible. Two people editing different fields of the same record is not a conflict unless the system insists on treating the whole record as one unit.
Handle the lock expiring. If editing reserves a record, say who holds it, when it frees, and give an admin a way to release it, because someone always closes their laptop mid-edit.
Retry the transient case automatically. Some rejections are momentary contention rather than a real disagreement, and a single silent retry resolves them.

Nobody minds being told someone else got there first, and everybody minds losing an hour of work to a save that reported success.