Business applications
What happens when two colleagues edit the same record?
Choose how a business tool protects a later change from silently replacing another person’s work.
Two colleagues open the same request. One updates the delivery instruction while the other corrects the contact details. The second save replaces the first change because the application treats an old screen as the whole current record.
Use a conflict people can recognise
For a fictional Estonia-connected business, prepare one request and two staff sessions. Make different edits without reloading. The team should agree whether the application can safely combine them, needs a deliberate review or should ask the second person to reopen the latest version.
The answer may differ for a contact spelling correction and an approval decision. A technical merge should not invent the business meaning of a consequential change.
Explain the decision at the moment it matters
If the record changed elsewhere, show an understandable message and preserve appropriate draft work so it can be reviewed. Avoid an unexplained error that makes staff type everything again or assume the save succeeded.
W3C's error guidance supports actionable feedback. The application still needs its own protection against stale changes and a suitable record of authorised decisions; a warning displayed only after data was overwritten is too late.
Review the resulting history
After resolving the test conflict, ask each colleague to identify the current instruction and the changes they made. Check linked messages or exports if those depend on the record. A sensible screen is insufficient when another system already received the wrong version.
A business application project should include this ordinary collaboration case before more people begin using it.
Further reading: W3C guidance on actionable feedback.