Agree ownership before sync

Video transcript

1. 0:00–0:06

   Define one exchange • Specify the trigger and accepted business state. • Source · approved request • Destination · operational order • Q17 · agreed fields • Technical response received • Receiving team ready? Still to establish • Define accepted state + acceptable delay + exception owner

   An illustrative approved request Q17 carries agreed fields to an operational order. A technical response and the receiving team’s business readiness remain distinct; readiness is still to be established. The exchange contract specifies its accepted state, allowed changes, acceptable delay and exception owner. No real-time requirement is implied.

2. 0:06–0:12

   Assign each field • Bidirectional sync is not unrestricted overwriting. • CRM contact • ERP billing • ERP order status • Editors send; receivers read · illustrative ownership • Change proposal → authoritative owner, not free overwrite

   Three separately revealed arrows preserve the hypothetical authority matrix: sales edits CRM relationship contact for operations to read; finance edits approved ERP billing for CRM to read; operations edits ERP order status for CRM to read with its update time. Pencil and eye endpoints distinguish editor from receiver. These are example roles, not universal CRM/ERP ownership rules. A proposal from the other system goes to the authoritative owner under an explicit conflict rule.

3. 0:12–0:18

   Keep native identifiers • Map records without using display names as identity. • CRM-C1042 • ERP-6021 • Display name · Supplier A • Display name · Supplier A Trading • Same mapped record · no new customer • ID mapping • Mapping missing or ambiguous? Review before creation

   CRM-C1042 remains mapped to ERP-6021 while the illustrative display name changes from Supplier A to Supplier A Trading. Neither native identifier changes and no second customer is created. A missing, ambiguous or unavailable mapping needs an understandable review state before any creation. Reconcile initial mappings and define how new records receive a mapping.

4. 0:18–0:24

   Inspect before replay • A timeout does not prove rejection. • Request applied? • ? • Check reference • Response lost · result uncertain • Inspect reference + related actions before replay • Verify mechanism scope and retention; no permanent guarantee

   The destination may already have applied the request even though the response was lost. Its outcome stays uncertain while the stable-reference inspection checks both the record and related notifications or other actions. A count of customer records alone cannot establish repeat safety. Verify the connector’s documented mechanism scope and retention period; a request key is not a permanent universal guarantee.

5. 0:24–0:30

   Give failures an owner • Pause, inspect, resolve and resume with history. • Automatic replay · paused • Named exception owner • Q17 · reference + history • Repeat-safe path • Resolve cause, then controlled resume • Partial effects and ordering conflicts stay explicit

   Automatic replay pauses before the affected Q17 reference and its history move to a named exception owner. Invalid data needs correction, temporary faults may allow bounded delayed retry, ordering conflicts need an authoritative version decision, and partial effects need an explicit resolution state. Coordinate manual correction with automated processing and resume only through the agreed procedure. These are proposed test/operating scenarios, not passing product results. Existing connector inclusions remain unchanged; review existing coverage before scoping gaps.