Illustrative example: a delivery moves to a different depot
At 09:00 a distributor’s order record shows the north depot. An assistant reads it and prepares a delivery note. At 09:03 a coordinator takes a call from the buyer, changes the destination to the south depot and adds new access instructions. At 09:05 a supervisor approves the earlier draft from a screen that still says north.
If the integration sends a complete copy of the old record, it can restore the old address as well as save the note. Sending just the note preserves the coordinator’s fields, but can still leave the warehouse with an instruction to unload at the wrong depot. The draft depends on the address even though it only changes the note.
The desired result is specific. The south depot stays on the order, the obsolete note stays out of dispatch, and the supervisor can see which detail changed. Accurate extraction from the original enquiry would still leave this problem.
Save the version alongside the proposed edit
When the assistant reads the order, keep its identifier, the destination’s version marker and the fields that influenced the proposal. For the delivery note, those might include depot, delivery date and access instructions. Store the proposed change separately until it is ready to apply. A reviewer should be able to see which order and version the draft came from.
At save time, send the expected version with the proposed change. The destination needs to compare and write in a single operation. A separate read followed by an ordinary write leaves a gap in which another person can edit the record. Shortening that gap reduces the opportunity for a collision but leaves it possible.
For HTTP APIs that support it, RFC 9110 defines If-Match with an entity tag to make a change conditional on the selected version. The wildcard form checks whether a representation exists. Use the specific version returned by the destination when the aim is to protect a colleague’s edit.
Check what the connector can enforce
Microsoft documents conditional updates for Dataverse tables that support optimistic concurrency. The client sends the record’s retrieved ETag with the update. If the record has changed, the documented conflict response is HTTP 412. Ask the integration supplier to demonstrate the behaviour on the table and connector you actually use.
In the Google Docs API, a batch update can specify requiredRevisionId. Google documents that an outdated required revision prevents the request from being processed and returns HTTP 400. Its targetRevisionId option has different behaviour and can incorporate collaborator changes. Choose the required revision when the reviewer expects the exact document they saw.
Some business connectors expose only a basic update action. Ask whether it passes a version condition to the destination. If it cannot, keep the suggestion in a separate draft or review task and let the operator resolve it in the business system. A workflow that serialises its own jobs still has to account for staff editing through another interface.
Give the reviewer a decision when the version changes
On a conflict, fetch the current record. Show the previous value, the current value and the proposed change. In the depot example, the supervisor can discard the north-depot draft, prepare a revised note, or ask the coordinator to clarify access. Preserve the original proposal for the review without copying unnecessary customer details into logs.
A record-wide version may also change because someone corrected an unrelated spelling mistake. Decide which fields can affect each draft. Where the system can establish that all relevant inputs still match and policy permits it, it can submit the narrow change against the newly read version. If a material input changed, prepare a fresh proposal and obtain any approval that action needs.
Avoid a retry rule that fetches the latest version and immediately resends the old payload. That makes the version check succeed while preserving the mistake. If the expected version of the order is current but the note also relies on a separate route plan, check that dependency too. An order version alone says nothing about a change to the route plan.
Rehearse one collision before allowing live writes
Use a test order and two sessions. Pause the assistant after it reads the north depot. Change the depot in the second session, then release the pending save. Check the destination record and dispatch view as well as the integration’s response. Verify that someone owns the unresolved draft and can complete the job using the corrected address.
Repeat with an unrelated edit and with a second change made while the reviewer is deciding. The next save should check its expected version again. Record how often staff encounter conflicts, how long they spend resolving them and whether any obsolete instruction reaches dispatch. A high conflict count may mean the assistant is reading orders too early.
Start with one editable field in one system. Give the process owner the results of the collision test and a sample conflict screen. They can then decide whether to allow automatic saves for that field, require review or keep the assistant in draft mode.