CRM integration: why it breaks after six months and how to spot it

Integrations rarely break on the day they are handed over. They break after three, six, nine months — once everyone has forgotten about them and nobody checks. And they break in a way that looks like nothing at all: pages load, the CRM works, there are no errors. Some of the data has simply stopped arriving.

Here are four typical causes. They share one property: the integration goes on believing everything is fine.

Why a CRM integration breaks: fields changed on the other side

Somebody added a required field in the CRM, renamed a pipeline stage, changed the list of statuses. To a person that is a small setting; to an integration it is a change of contract. It keeps sending data in the old shape while the receiving side rejects it or quietly drops what it does not recognise.

The required-field case is particularly unpleasant: deals stop being created, but the error goes into an integration log nobody reads. For a while the sales team assumes customers have simply stopped writing.

Access expired or changed

Tokens do not live forever. Some services issue them for a year, some revoke them when an admin password changes, some when the employee whose account everything was set up under leaves.

The integration then gets an access refusal and, in most implementations, simply skips the cycle: the data did not go, the next attempt is in an hour, and so on indefinitely. From outside the symptom is that data "lags" and then stops appearing altogether.

Make it a rule: integrations run under a dedicated service account, not under a person. Otherwise the first holiday or resignation turns into an incident.

The volume grew

An integration written for a hundred deals a day may not survive a thousand. What it usually hits is not speed but limits: requests per minute, maximum payload size, response timeout.

Past the limit the external service refuses or drops the connection. With no retries in the code, part of the data is lost silently. The signature is that the losses move around: today one set of records did not arrive, tomorrow another, with nothing in common.

The process changed and nobody touched the integration

The most common and most galling cause. The team started running deals differently: a stage was added, the routing rule changed, customers are now created another way. The integration keeps doing what was agreed six months ago, and as code it is perfectly healthy — its work simply no longer matches how people work.

There is nothing to fix technically. The only remedy is that somebody remembers the integrations when the process changes — which means they need an owner.

How to build an integration that reports its own failure

The difference between a fragile and a dependable integration is not code quality but feedback. Here is the minimum worth insisting on.

• A silence alert: if nothing came through in a day where dozens usually do, the system should tell a human. That catches most failures.
• Retries on network errors, and a separate notification when the retries are exhausted.
• Regular reconciliation: once a day compare record counts on both sides and report any gap.
• Notifications where they will be seen: a messenger, not a log file on a server.

How to check your integration today

• When did data last pass through it? If you do not know where to look, that is the answer.
• Compare yesterday's record counts on both sides. The gap should be zero.
• Find out whose account it runs under. If it is a named employee, plan the move to a service account.
• Ask what happens if the external service is unavailable for three hours. Test the answer "the data will catch up later" in practice.

An integration is not a one-off job but part of your infrastructure. It does not need constant maintenance — it needs the ability to say that something is wrong. Without that you hear about the failure from a customer, usually in the most unpleasant way.