A sales coordinator opens a customer record to change its contact details. While that screen remains open, a colleague updates the account status. The coordinator saves an older copy and the new status disappears. Both staff may have followed the application’s normal workflow; the system failed to make the conflict visible.
For a UAE business commissioning a CRM, booking system or internal portal, concurrent editing belongs in the acceptance criteria. Ask what the application does when information changes between opening a screen and saving it.
Concept illustration of competing edits and a version check, not an authentic application screenshot or an ITZ client project.
Define the business consequence of an overwrite
Start with records that several people update: quotations, stock reservations, customer details or job assignments. Identify which fields can change independently and which decisions depend on the whole record being current. A harmless notes update and approval of a changed order are not necessarily the same kind of conflict.
Write a concrete rule. For example: if the order changed after a manager opened the approval screen, the system must show the updated information before approval. This is a proposed requirement, not evidence that an existing application already enforces it.
Ask for a server-side version check
Microsoft’s Dataverse optimistic concurrency guidance describes detecting whether a record changed between retrieval and an update or delete. Its SDK supports a row-version comparison and reports a mismatch when the submitted version is stale. Support and implementation depend on the table and API used; the documentation is a platform example, not a promise that every CRM automatically protects every save.
Ask the developer where the comparison is enforced. A warning in the browser is insufficient if another integration or API route can overwrite the same record without an equivalent check. Review the actual write paths, including imports and scheduled jobs.
ITZ’s custom software development service can help turn these business rules into application behaviour. Request an application edit-conflict review with one affected record type and the roles that update it.
Decide what staff see after a conflict
A useful response preserves the employee’s unsaved input, explains that a newer version exists and provides a way to review it. Avoid a generic error that leaves the user guessing whether anything was saved. Do not silently retry the stale write until it succeeds.
- Independent fields: the team may approve a carefully defined merge, with the final result shown clearly.
- Competing values: a responsible user needs to compare the old, submitted and current values before choosing.
- Dependent decisions: an approval or allocation may need to restart against the current record.
- Background updates: route unresolved conflicts to an accountable queue rather than discarding them.
The correct policy depends on the process. A version check detects a stale operation; it does not decide which business value is right. Audit information should help explain the resolution without unnecessarily exposing sensitive data.
Run a two-user acceptance test
- Use an authorised test environment and a harmless sample record. Have two users open the same starting version.
- Let the first user change and save an agreed field. Confirm the stored result.
- Have the second user submit the older screen. Verify the expected conflict, preserved input and absence of silent data loss.
- Resolve the conflict through the supported workflow and inspect the final record and relevant history.
- Repeat with an integration updating the record while a person edits it, including failure and retry handling.
Use the safe integration retry guide alongside this exercise. Avoiding duplicate records and avoiding stale overwrites are different requirements. The data import reconciliation guide helps verify bulk-write outcomes.
Review Your Application Edit Conflicts
Bring ITZ an example of the record, its editors and the consequence of a wrong overwrite. We can discuss version checks, resolution rules and acceptance tests. Review Your Application Edit Conflicts using the contextual form below.
Primary guidance reviewed on 30 October 2026. Examples are proposed checks, not client case studies.
