Custom software
Two people changed the same order. Which edit should survive?
A practical approach to concurrent order changes: detect stale edits, show the difference and let the right person resolve the business decision.
The saved message can hide a lost decision
A salesperson changes an order’s delivery instruction while an operations coordinator updates its requested ship date. Both see “Saved.” Later, one change is missing.
The problem is not necessarily that somebody forgot to save. Each person may have opened the same old order, changed one field and submitted a complete copy. If the second copy replaces the first, an untouched but outdated field can overwrite someone else’s work.
This illustrative situation is a useful test for any shared order tool. A successful save should mean that the intended change was accepted—not that the system silently decided which colleague’s work to discard.
A warning banner is not a complete conflict rule
Teams sometimes address this with a message saying another person has the order open. That can help people coordinate, but an open browser tab is not a reliable statement about who is actively editing. A forgotten tab should not stop the warehouse all afternoon. Conversely, the absence of a banner should not mean an import or integration cannot update the order.
The stronger question is: Does the submitted change still apply to the record the person reviewed?
One proposed design gives every saved order revision a version identifier. When a person opens an order, the application remembers that version. When they save, the server checks the expected version and applies the update as one controlled operation. A mismatch becomes a visible conflict, not an automatic overwrite. Checking the version in the browser alone would leave a gap between checking and saving.
Database behavior matters underneath that design. Under Read Committed, PostgreSQL rechecks an update condition against an updated row after a concurrent updater commits. Its locking guide also explains that locks can block other work and that long transactions waiting on user input are undesirable. These mechanisms support an implementation; they do not decide which delivery promise the business wants to make. PostgreSQL transaction isolation and explicit locking.
Show the three values that explain the conflict
Consider this proposed review screen:
Requested ship date — When you opened it: Monday. Saved by your colleague: Tuesday. Your submitted value: Monday, unchanged.
Delivery instruction — When you opened it: Loading dock. Saved by your colleague: Loading dock. Your unsaved change: Call receiving first.
The screen should distinguish an intentional edit from an old value merely carried along in the form. In this example, the changes concern different fields. A carefully designed merge could retain Tuesday and add the receiving instruction. Before enabling that behavior, however, the team must decide whether those fields can truly change independently. An instruction such as “deliver before shutdown” might affect the date decision.
Now change the example: both people edited the requested ship date. There is no neutral way to choose between their business intentions. Present both changes, identify the current saved revision and let an authorized person decide. Saving a resolved conflict must check the latest revision again; another update may arrive during review. Preserve the unsaved text while they review. “Refresh and try again” without preserving their work makes a technical conflict into avoidable re-entry.
Test the awkward cases, not just two open tabs
A bounded trial can use a test order and a short set of scenarios:
- Two people edit the same field. The second save must not silently replace the first.
- Two people edit different fields. The result must follow the agreed merge rule rather than a convenient technical default.
- An integration updates the order while a person is editing. The same conflict protection should apply.
- A person closes the conflict dialog. Their unaccepted change must not appear as committed.
- An order enters a non-editable business state during editing. A fresh version alone must not bypass that state rule.
- A save returns an uncertain result. Inspect the actual order revision before offering a retry that might repeat a separate downstream action.
These are proposed acceptance cases, not reported test results. They also reveal a limit: protecting one order record does not automatically coordinate reservations, invoices and external shipping systems. Those dependencies need their own transaction and recovery design.
Start with the screen that causes the most rework
Do not begin by locking every record in every application. Pick one frequently shared editing screen, document which fields may merge and which need a decision, and build a visible conflict path. Include the integration writes that touch it.
A useful first software scope is a review of that screen, its save operation and its conflict tests. The deliverable is a rule people can explain: what was saved, what was not, and who chooses the remaining change. It is a more specific starting point than asking for a wholesale order-management replacement.