CRM Integration: What Actually Breaks and Why

Almost every failed integration we've been called in to rescue failed the same way. It wasn't a bad API or the wrong middleware. It was a disagreement about what a customer is.

Integration usually gets sold as a plumbing problem. Connect system A to system B, move the records across, done. But the plumbing is the easy part. What actually breaks projects is that two systems, built by different vendors for different departments, have quietly different definitions of the same business object, and nobody surfaces that until data is already flowing.

Here's what really goes wrong, roughly in the order we run into it.

1. The two systems disagree about identity

Your CRM thinks a customer is a person with an email address. Your ERP thinks a customer is a billing account with a tax number. One human buying under two entities becomes two CRM contacts and one ERP account, or one contact and two accounts, depending on who set it up.

Sync those naively and you get duplicates. Or worse, silent merges that attach one company's orders to another company's record. This is the single most common cause of "the integration works but the data is wrong".

What to do: before anyone writes code, decide which system owns identity and what the matching key actually is. Email isn't a key, because people change jobs and share addresses. Usually what you need is a deliberate mapping table that both systems reference and neither one owns.

2. Nobody decided which system wins

A record gets edited in the CRM and in the ERP on the same afternoon. Which one is right?

If you can't answer that field by field, you don't have a specification yet. Most integrations need field-level ownership rather than system-level. The CRM owns contact details and pipeline stage, the ERP owns credit terms and invoice history, and neither one writes to the other's fields. "Last write wins" is still a decision, it's just a decision made by accident, and it's usually the wrong one. It means whichever system happened to sync most recently overwrites deliberate work somebody did in the other.

3. It works perfectly on the happy path

The demo syncs a clean record and everyone signs off. Then production supplies reality: a customer with no email address, a name in Arabic script, an order for a product that was deleted last year, a country field containing "UAE" where the other system expects "AE", a phone number carrying a leading apostrophe from a spreadsheet import in 2019.

Every one of those is a decision. Skip the record? Write a partial one? Fail loudly? An integration with no explicit answer for malformed input will pick one silently, and it usually picks "skip". That's how you end up with a sync that reports success while quietly dropping 4% of your customers.

4. It fails silently

This is the expensive one. A token expires, a vendor changes a field, a rate limit trips, and the integration stops. No alert, no dashboard, no error anybody sees. The business runs on stale data for days or weeks until someone notices the numbers don't add up, and then you're reconciling by hand.

Rate limits are the trap people underestimate, because the ceiling looks comfortably far away right up until it isn't. Salesforce, for instance, allocates Enterprise Edition orgs 100,000 API calls per rolling 24 hours plus 1,000 per user licence, counted across REST, SOAP, Bulk, and Connect together. Cross it and your calls start coming back 403 REQUEST_LIMIT_EXCEEDED. A nightly sync that polls record by record instead of batching can burn through that allocation in an afternoon, and it'll do it quietly, six months after launch, once your record count has grown.

What good looks like: retries with backoff for transient failures, a dead-letter queue for messages that genuinely can't be processed, and alerting that actually reaches a human. The test is simple. If this integration stopped right now, how long before anyone found out? If the answer is more than an hour, it isn't monitored.

5. It can't be re-run safely

Something breaks, you fix it, and now you need to reprocess three days of backlog. If replaying those messages creates duplicate orders, you can't recover without manual clean-up, so in practice nobody replays and the gap just stays a gap.

Idempotency is what makes recovery possible. Processing the same message twice produces the same result as processing it once. It isn't hard to build in from the start and it's genuinely painful to retrofit, so ask for it explicitly.

6. The vendor changed something

Third-party APIs deprecate fields, change rate limits, and adjust authentication. A well-built integration degrades predictably: it logs the unexpected shape, raises an alert, and keeps processing whatever it still can. A fragile one throws an unhandled exception and stops dead.

Nobody can prevent vendor change. What you can control is whether it turns into an outage or a ticket.

What a real integration project includes

When we scope this work, roughly half the effort isn't the connection itself:

• A field-level mapping document. Every field, its source of truth, its transformation, and what happens when it's missing. This is the actual specification, and the code follows from it.
• An identity strategy. Matching keys, duplicate handling, and what happens when two records you thought were separate turn out to be the same company.
• Failure handling. Retries, a dead-letter queue, alerting, and a documented recovery procedure.
• Idempotency, so replaying anything is safe.
• A runbook. What breaks, how you'll know, how to fix it. Written for your team, not for us.

A single well-defined integration typically costs €6,000–€20,000. A multi-system integration layer runs €25,000–€75,000. The range comes down almost entirely to how cooperative the systems on each end are. A modern documented API at both ends is a fraction of the work of a legacy system with no API and a database you're permitted to read on Tuesdays.

When you shouldn't build a custom integration

We say this often enough that it's worth writing down. If an off-the-shelf connector does the job, use it. Zapier, Make, and native vendor connectors handle simple, low-volume, well-shaped syncs perfectly well, at a fraction of the cost of custom work.

Custom earns its money when you need complex transformation, high volume, guaranteed delivery, non-trivial business rules, or a level of reliability no-code tools can't promise. If your requirement is "when a deal closes in HubSpot, create a row in a spreadsheet", please don't commission an engineering project.

The honest test: if you can describe the whole integration in one sentence with no "except when" hiding in it, start with a no-code tool.

Got a sync that keeps breaking, or a manual process nobody will admit to? Tell us which two systems are involved and what the weekly workaround looks like. That's usually enough for us to scope it. You can also read how we handle API and integration work, or walk us through the workflow.