WEB-043 · Synthetic planning example · 2 October 2026
Customer details: ownership and conflict example
Use this example to agree who can change each customer detail, who settles a disagreement and when staff can rely on the result. All records and events below are invented. This static file does not connect to any system.
1. Decide who owns each detail
| Detail | Who approves it | Direction and boundary |
|---|---|---|
| Customer match | Account owner | Sales record S-204 is confirmed as operations record O-806. Never match by a similar name alone. |
| Payment status | Finance, in the operations system | One way to sales; sales cannot overwrite it. |
| Account manager | Sales | One way to operations; operations cannot overwrite it. |
| Delivery entrance | Sales or operations can propose a change; the account owner settles disagreements | Two way for this field only. Different edits from the same agreed starting value require review. |
2. Follow one disagreement to agreement
Starting inputs
One matched customer, S-204 / O-806. The agreed entrance is North (decision R1). Finance shows Paid and sales names Lina as account manager. Those two owned fields remain unchanged throughout.
Conflicting edits
Sales proposes East (event S-E1); operations proposes West (event O-E1). Both were based on R1, before seeing the other edit. Current local copies differ. Hold automatic copying of this field, show both proposals and ask dispatch to confirm the entrance before use.
Human decision
The account owner checks with the customer and approves East as decision R2. Record the approver and reason. Read both current record versions and check that the reviewed entrance values are still East and West. A new entrance edit requires a fresh review.
Confirmed output
Write East only to this matched customer, provided each record still has the version just checked. Verify East in both systems. Close R2 only after both confirm it. Sales and operations now show East; payment status stays Paid and account manager stays Lina.
If completion is interrupted
Keep R2 pending if only one system confirms. Do not call the copies aligned or undo the successful write blindly. Read both again before a bounded retry. If an entrance changed meanwhile, return to review. A named account owner handles unresolved items within an agreed business deadline.
3. Check the exceptions before accepting a connection
| Test input | Expected outcome |
|---|---|
| Both teams propose East from R1 | No disagreement in the value. Verify East in both copies before recording alignment. |
| Sales proposes East; operations proposes West from R1 | Review required. Never choose a winner solely because its timestamp is later. |
| Entrance changes after the owner reviews it | Reject the stale write through a version check. Read again and return the new proposal to review. |
| R2 reaches one system; the second is unavailable | Show Pending. Recheck both values and versions before retrying; complete only on confirmation from both. |
| The same event S-E1 arrives twice | Recognize its already-recorded event ID. Do not apply it again or open another decision. |
| A copy made by this connection is sent back as a new notification | Recognize the connection’s origin and decision ID; verify the copy without circulating it as a new user edit. |
| An old R1-based update arrives after downtime, after R2 completed | Compare its agreed starting revision with current R2. Hold the outdated event; it cannot overwrite East. Record that it was held. |
| One customer record is deleted while the other still exists | Pause this customer’s updates and ask the account owner to review. Do not copy the deletion or recreate the record automatically. Keep the deletion decision separate from normal edits. |
| An old event arrives after an approved deletion | The retained deletion marker blocks restoration by replay. Retention and lawful deletion requirements must be agreed for the real system. |
| No confirmed customer match, or an empty entrance value | Hold for correction. Do not create a customer, guess a match or treat blank text as an approved deletion. |
What this example assumes
This is a proposed acceptance model, not a description of every connector. It assumes confirmed customer matching, a stored agreed revision, identifiable events and origins, version-aware writes, an approval record and a visible review queue. Record-version tokens are compared for equality, not treated as dates or ordered numbers. The systems may temporarily disagree; the pending state must be visible wherever staff act on the instruction. If your software cannot support these safeguards, limit editing to one owner and use one-way copying until a suitable approach is tested.
Sources and practical use
IBM explains one-way and two-way synchronization. HubSpot documents selectable direction, mapping and a default app for conflicts; it does not establish that this proposed human review exists in every connector. Microsoft Dataverse documents conditional writes and their prerequisites. These sources support individual concepts, not an implemented or certified end-to-end solution.
The downloaded HTML includes the diagram and text. Fonts fall back to your device fonts offline. The SVG contains editable draw.io data.