System Integration: How Do You Prevent Conflicting Edits?
Start with the short answer ↓
When two tools edit the same business record, a successful save can hide a lost change. Define field ownership, check the version being edited and give stale or conflicting updates a visible resolution path.
Prepared with AI assistance. These are practical scoping recommendations; examples are illustrative, not client results.
A successful save can still lose somebody else's work
A dispatcher changes a work order's delivery window. An office employee, working from an older screen, adds access instructions and saves a copy that still contains the previous window. Both people were allowed to work on the order. Both screens may report success. The integration has nevertheless restored a value that nobody intended to restore. This is an illustrative design scenario, not a customer incident or a claim about a delivered connector.
This is a concurrent-edit problem: the second writer acts on an outdated base. It differs from receiving old notifications out of order. Fixing message delivery order cannot, by itself, protect a human edit made through another application. Before connecting two editable tools, ask what stops a stale copy from replacing an accepted change.
Handle delayed notifications separately from competing edits
Decide which fields each side may change
Map the shared record's identity and the authority for each business value. One system may own the confirmed delivery window while another submits a requested change. Copying a confirmed value and requesting a new decision are different operations. Technical access to an update endpoint does not establish that the sending team owns every field in its payload.
Record the intended edit separately from the last downloaded object. If staff only changed access instructions, the receiving workflow should not silently treat every other value on their old screen as a fresh instruction. A narrower update can reduce accidental replacement, but PATCH or a changed-fields list alone is not proof that simultaneous changes to the same value are safe. Confirm the actual API contract and business relationships between fields.
Define the field-level source of truth before resolving conflicts
Use a conditional write where the API supports it
HTTP's If-Match condition lets a client make a write depend on the resource's current entity tag matching the version it previously read. RFC 9110 describes this as a way to prevent lost updates. A failed condition must not become an unconditional overwrite. Treat the returned tag as an opaque value; do not invent a chronological sequence or compare tags from different systems.
Google Calendar documents a concrete example: a supported modification supplies the earlier etag in If-Match and receives 412 when the resource has changed. Its conditional-modification support does not apply to insert operations. Verify the exact operation you need; a version field displayed somewhere in a product does not prove that its update API enforces a precondition.
Our proposed acceptance contract is simple: if the base changed, preserve the attempted business edit without applying it blindly. A version check performed only in the connector's memory is not enough if another writer can change the destination before saving. The destination needs an enforceable conditional operation or another verified control appropriate to that workflow.
Walk through one stale work-order save
Suppose two authorized interfaces read work order WO-31 at base A. The delivery window is 10:00–12:00 and the access note is call on arrival. The dispatcher changes the window to 14:00–16:00, creating current state B. The office employee still has A and changes only the access note to use the loading entrance. The letters are invented labels for this example, not values to derive from a provider's etag.
The office save must not restore 10:00–12:00 from its stale copy. In an implementation with enforced conditional writes, the stale-base attempt is refused. The application retains the office employee's intended note and reads B. If the note is unchanged in B, the employee has authority to edit it and no related business rule prevents the combination, a fresh conditional update may apply only that note against B. The accepted result keeps 14:00–16:00.
Change one fact: the dispatcher also changed the access note. Now two authorized proposals affect the same business value. Refreshing the version and resubmitting the office text would merely hide that disagreement. Show the base, current and proposed notes to the appropriate owner, who chooses the permitted result. If either field affects route feasibility, review that relationship before treating the edits as independent.
Choose the resolution from the difference, not the arrival time
The following worksheet is our proposed business decision aid, not a universal merge algorithm. Compare the version originally read, the current accepted record and the intended edit. Do not assume that the most recent timestamp proves authority or that a record with more completed fields should always win.
| Observed difference | Proposed handling | Evidence to retain |
|---|---|---|
| Another field changed; the proposed field did not | Check authority and cross-field rules, then prepare a fresh narrow conditional update | Base, current version, intended field and accepted result |
| The same field changed to a different value | Route both proposals to the field owner; do not silently choose the later arrival | Competing values, source references, reviewer and decision |
| The current field already equals the intended result | Verify the required business outcome; do not repeat side effects automatically | Current value and any linked action's actual status |
| The record was closed, deleted or access changed | Recheck whether the operation is still permitted; do not recreate or reopen by accident | Current state, permission result and next owner |
| No usable version or comparison is available | Narrow editing authority or use a supported review/single-writer path | Documented API limitation and the tested fallback |
A refreshed version is not permission to retry the old decision
Google's Calendar guidance offers re-reading the resource and reapplying changes after a failed precondition. The business still needs to decide which changes remain valid. A sample that rewrites one event field is not a conflict policy for every CRM or operations workflow. Keep that judgment explicit, bounded and owned.
After reading current state, the record can change again. Any later write still needs the supported protection; do not remove the condition just to make a retry succeed. Bound attempts and route repeated contention to a visible queue with the intended edit, reason, owner and next action. Do not report the integration complete while an unresolved edit is merely parked in a background loop.
Also separate the record update from downstream effects such as notifying staff or reserving a resource. A successful conditional save in one API is not a transaction spanning two systems. If the next step times out, determine what actually happened before repeating it. Likewise, a connector queue controls only writers that pass through it; it does not automatically lock people editing directly in the destination.
Distinguish retrying an action from resolving a changed record
Accept the integration with two deliberate writers
Use isolated test accounts with real notifications and consequential writes disabled. Have both interfaces read the same base, then save in each possible order. Test separate fields, the same field, related fields that cannot be combined, a closed record and a change made outside the connector. Add another change between conflict detection and the next attempted save. This exercise should use the actual supported API operation, not only a mocked success response.
For each case, specify the final record, edits that must remain unsaved, permitted downstream effects and the review evidence staff need. Verify the accepted state in the owning system. A green synchronization badge, a 200 response or an empty queue alone does not demonstrate that the correct business decision survived.
The release receipt should name the record type, field authority, provider/operation assumptions, version boundary, observed conflicts and tested fallback. Keep necessary references with appropriate access and retention rather than copying full customer records into a general log. Start with one disputed record type; widen the integration only when staff can understand both a successful update and a deliberately rejected one.
Scope system integration around the records your teams share
Primary references
The guidance above is AgenticShip's proposed approach. These references provide technical background for the relevant recommendations.