Give every shared field an owner before connecting two systems
Define record identity, update direction and conflict handling for a CRM and accounting integration.
Start with one business event
Take a fictional small distributor connecting its CRM to its accounting system. A salesperson marks a quote as accepted; finance then creates the billing record. Describe that event and its finished state before selecting a connector. The result needs a stable link between the accepted quote and the billing customer. It does not require every field in both products to update in both directions.
Assign authority by field
Write a field register with the business meaning, authoritative system, allowed editor, destination and update rule. In the example, CRM owns the sales contact and quote status. Accounting owns the billing account code and posted invoice number. A single 'customer' object can therefore contain fields with different owners. Agree what happens when a user edits a copied value in the receiving system: reject the edit, flag a conflict or make it an explicit override.
Preserve the identifier pair
Store CRM company ID B-10 beside accounting customer ID A-407. Do not resolve every message with a new name search. An amended company name must update the existing mapping rather than create another billing customer. Record how a merge, deletion or reactivation affects that pair. Keep a review queue for messages whose identifiers cannot be resolved; silently guessing a match creates errors that surface later in invoices.
Design for partial completion
A local update and a remote message are separate operations. AWS describes the transactional outbox pattern for recording a business update and the event to be sent within the same local transaction. That pattern does not make the receiving system immune to duplicates. If your connector cannot support an outbox, document its actual delivery and recovery behaviour, then choose a reconciliation process that detects missed or repeated work.
Make conflicts visible
For the fictional distributor, an address change made in CRM does not overwrite an address already used on a posted invoice. It creates a review item for future billing details. The item records the source record, changed fields, message ID, time and person responsible. Avoid copying a complete customer payload into a broadly accessible error log. Keep only the diagnostic information needed by authorised support staff.
Test the awkward sequence
Rehearse duplicate delivery, a timeout after remote success, an old event arriving late, an unknown customer and a temporary outage. For each case, define the expected number of business records and the route for a person to resolve an exception. End with an integration register: field owners, identifier mapping, delivery behaviour, review queue and support owner. A connector's list of supported applications does not answer these operational questions.