Concurrent business-record editing: preventing the last save from overwriting earlier work
Check the version a user edited against when saving. If the record changed, preserve the draft, retrieve the current record and decide whether to merge or restart the action without silently overwriting another person’s work.
On this page5 sections
Preventing lost work in a shared business record starts with checking which version the user edited. If that record has changed, preserve the new input and explain the conflict rather than report a successful save that overwrites someone else's work. In a software development scope (Chinese), specify conflict detection, difference presentation, renewed confirmation and resubmission. Verify the stored result as well as the message shown on screen.
Reproduce the problem with two saves
Suppose Alice and Bob both open version 12 of a purchasing record. Alice changes the delivery address and saves version 13. Bob then changes the contact person but submits the complete older form. An unconditional replacement could restore the old address. Editing different fields does not by itself prevent lost updates when the application submits an entire record.
Use a server-controlled version rather than relying on each browser's clock. Microsoft's EF Core documentation describes comparing an original concurrency token during a write. HTTP If-Match is another conditional-write mechanism, with a 412 response when its condition is not satisfied. These mechanisms detect a condition; the business still has to decide how the resulting conflict should be resolved.
Choose record rejection or field merging by business relationships
Start with a rule that can be explained and tested: a relevant change to a critical record requires renewed confirmation. Consider automatic merging only for fields that are demonstrably independent. Quantity and unit price, warehouse and reserved stock, or approval state and editable fields may jointly determine a business result. Different field names are not sufficient evidence that their changes can safely coexist.
| Change | Suggested behavior | Business decision |
|---|---|---|
| Both people changed the same field | Show the difference for selection or fresh entry | Who may determine the final value? |
| Separate descriptive fields changed | Consider merging with a change record | Are the fields genuinely independent? |
| State or a critical relationship changed | Reassess whether the original action is still allowed | Can that action continue? |
Preserve three versions of the relevant information
A useful conflict screen distinguishes the value when editing began, the value currently stored and the value the user is trying to submit. Highlight actual differences instead of making the user reread every field. Retrieve current values under the user's current permissions; a conflict message must not reveal fields whose access has been revoked. Before reloading, explain how unsaved input will be handled so protecting a colleague's change does not discard the user's long draft.
After a person resolves the differences, save against the newly read version. We recommend making the comparison and write a protected server-side operation. A separate preliminary read followed by an unconditional save still leaves time for another writer to intervene. If another conflict occurs, retain the user's resolution and review it again. Do not quietly turn the second attempt into an unconditional overwrite.
Some conflicts require a different business action
While Bob is editing, the record may be approved, deleted or transferred to another department. Distinguish changed content from an action that is no longer permitted. For example, merging an old form must not reopen a closed work order by restoring its former state. Reopening, when allowed, should be an explicit action with the appropriate authorization rather than a side effect of saving stale fields.
If a genuine requirement exists for force overwrite, restrict the role, explain the affected scope and record the action. It should not be the default escape route after any failed save. Describe retained input, changed permissions and deleted records using the preconditions and exception branches in the requirements-document guide. A generic notice that data changed is not enough to tell someone how to finish their work.
Control the test sequence and inspect the final record
- Open one version with two accounts. Edit the same field and save in sequence. Confirm detection of the second save and preservation of the first value.
- Edit different fields. Verify the agreed whole-record rejection or merging rule, not merely a success message.
- Make a third change during conflict resolution. Confirm that the resolved submission still has version protection.
- Approve, delete or revoke access during editing. Confirm that the stale screen cannot bypass the current restriction.
Record starting versions, submission order, expected values and final stored values in business user acceptance testing. If one record type repeatedly conflicts, evaluate a short reservation or editing lock. Any lock introduces additional questions: leaving the page, disconnection, expiry and authorized release must all work. Avoid replacing silent overwrites with records that remain locked after their editor has disappeared.