Duplicate records, sync loops and silent failures. How to define the system of record, handle errors properly, and integrate a CRM that stays trustworthy.
CRM integrations rarely fail at the technical level. They fail because two systems disagree about what is true, and nobody decided in advance which one wins.
Decide the system of record, per field
Not per system — per field. The website may own marketing preferences while the CRM owns account ownership and the finance system owns billing address. Write this down as a table before any code is written. Most integration disasters trace back to skipping this step.
The four failures that recur
Duplicate records
Two systems create the same person twice because they match on different keys. Decide your match key — usually email, sometimes an external ID — and enforce it on both sides. Then decide what happens on a near-match, because "sarah@company.com" and "s.jones@company.com" are the same human and no automatic rule catches that reliably.
Sync loops
System A updates a record, which triggers a webhook to system B, which updates and triggers a webhook back to A. Prevent it with an origin marker on each write, and ignore updates you caused yourself.
Silent failures
The integration stops working and nobody notices for six weeks, by which time the data is a mess. Every integration needs a heartbeat and an alert on failure. "It has not synced anything in an hour" should page someone.
Field mismatch
One system's picklist has eleven values, the other has seven. Map them explicitly, including a rule for the unmapped ones, and never let a value silently drop.
Log every write, both directions. When someone asks in three months why a record says what it says, the log is the only thing that answers. Retain it long enough to be useful.
Batch or real-time?
| Real-time | Batch | |
|---|---|---|
| Best for | Sales-critical events — new lead, deal closed | Bulk reconciliation, reporting data |
| Failure mode | Missed webhook, silently lost | Delay, but easy to re-run |
| Complexity | Higher — retries, ordering, idempotency | Lower |
Most integrations should be both: real-time for the handful of events where minutes matter, and a nightly batch that reconciles everything and catches whatever real-time dropped.
Make every write idempotent
Assume every message will be delivered twice at some point, because eventually it will be. If processing the same event twice creates two records or sends two emails, the integration is not finished.
What to agree before building
- The system-of-record table, field by field
- The match key and the duplicate-handling rule
- What happens when the other system is down — queue, drop or fail loudly
- Who is alerted on failure, and how
- How you will reconcile and prove the two sides agree
Frequently asked questions
Should we build the integration or use a connector tool?
Connector platforms are excellent for standard object mapping and save real time. Build custom when the logic is genuinely yours — complex routing, unusual matching, or business rules the tool cannot express.
How do we handle GDPR in a CRM integration?
Sync consent state as a first-class field, not an afterthought, and make deletion propagate. A deletion request that clears the CRM but leaves the copy in your marketing tool has not been honoured.
How long does a CRM integration take?
A standard lead-capture sync, one to two weeks. Bidirectional sync with real business logic, one to three months — most of which is agreeing the rules, not writing the code.
