Two people can open the same record, make different changes and both receive a successful save message. Without a conflict check, the second save may silently replace the first person's work.
This is a product problem worth solving explicitly. The user needs to know when the record has changed since they opened it, and the application needs a way to prevent an old view from overwriting a newer one without review.
Give the record a version
When the application returns an editable record, include a version value suitable for checking subsequent writes. That might be a database version counter or another representation that changes whenever the relevant data changes.
The save request should carry the version the user edited. The server then compares it with the current version as part of the write operation. A separate read followed by an unconditional update can still race with another save.
For a hypothetical operations dashboard, two staff members may edit different notes on the same customer record. The application should detect the overlap before one person's complete form submission erases the other's update.
Use the protocol where it fits
HTTP entity tags can represent a resource version. A client can send an If-Match condition with a write, and the server can reject it when the supplied version no longer matches. The MDN ETag reference describes this use for preventing conflicting updates.
That mechanism still needs correct server implementation. Generating a tag is not sufficient if the database write ignores it or if the tag fails to change when important fields change.
Choose the version boundary around the editing task. One version for a very large aggregate may produce frequent conflicts; versions that are too narrow may miss related changes that should be reviewed together.
Preserve the user's attempted change
A conflict response should not simply clear the form. Show that the record changed elsewhere and keep the user's input available. Offer a way to compare with the current value and decide what to apply.
Automatic merging is appropriate only where its meaning is clear. Combining two independent appended notes may be straightforward. Combining a changed quantity, an approval state and a date can require a business decision.
Avoid a prominent “force save” action unless the user has the authority and context to overwrite the current state. Where overrides exist, make their effect explicit and retain a suitable change history.
Test the actual race
Open the same test record in two sessions. Save a change in the first, then submit the stale form in the second. Confirm that the second request is rejected or reconciled according to the intended behaviour, and that neither user's work disappears without explanation.
Also test an unchanged form, a deleted record and a background process updating the record between load and save. The browser is not necessarily the only writer.
Version checking can make an ordinary admin screen much more dependable without requiring a complex collaboration system. Our internal-tool engineering treats these concurrent editing cases as part of the workflow, especially when the data drives actions elsewhere in the business.