A connection is not a data policy
An ERP and CRM may both store customer names, addresses and order details. Connecting their APIs does not decide which value should win when the records differ. That decision belongs in the integration scope.
Start with a field ownership map. For each field, record the owning system, allowed direction of change, stable identifier and people who may correct it. Ownership may differ by field: an enquiry status can belong to the CRM while an approved account reference belongs to the ERP.
Define identifiers and lifecycle events
Choose an identifier that survives routine name or email changes. Decide when a prospect becomes a customer, when an order is approved and when a cancellation should stop downstream work. Include archived and deleted records in the discussion.
For an illustrative customer record, the CRM may hold an enquiry identifier before the ERP issues an account reference. The integration should preserve the relationship between those identifiers rather than repeatedly matching by display name. This is a design example, not a description of a specific customer's data.
Make retry and conflict rules explicit
A delayed update and a retry can arrive after a user has changed the record. Agree whether to reject an old update, route it to a review queue or apply a field-level rule. Avoid promising that whichever event arrives last is necessarily correct.
Document how a repeated event is identified and how to check whether the destination already completed the action. A timeout is not proof that no change occurred. Use a bounded recovery process instead of unrestricted retries for sensitive actions.
Add reconciliation alongside event delivery
Event delivery answers whether a message was sent. Reconciliation checks whether the records now agree. Define which records are compared, how discrepancies are reported and who approves a correction.
Keep access limited to the fields and operations the integration needs. Agree which diagnostic information can be logged and how operators find a failed record without exposing unnecessary customer data.
Treat initial migration separately
A historical import has different risks from ongoing updates. Assess duplicates, incomplete fields and old identifiers before the import. Rehearse using approved test or redacted data, reconcile totals and relationships, then agree cutover and rollback criteria.
The proposal should list the supported objects, documented API assumptions, access dependencies, failure handling, handover and support responsibility. Timing depends on those decisions and the condition of the existing data.
Prepare a focused discovery brief
Bring a sample field map without private customer details, the API documentation, approximate volumes and the people who own each system. Discuss an ERP and CRM integration scope around one useful flow before expanding the connection to every object.