Decide which system owns each piece of information, integrate through events instead of syncing everything with everything, and log every exchange. Most integrations that fail silently do so because ownership was never settled and nobody was watching.
In nearly every mid-sized company there is someone whose job, in practice, is copying data from one system into another. The order arrives by message, someone enters it in the ERP, someone repeats it in the CRM, someone marks the calendar. Four keystrokes of the same fact and four chances to get it wrong.
First, who owns each piece of information
Before any code, settle the political question. For each important record, one system is the source of truth and the others hold copies.
Customer records: do they live in the CRM or the ERP? If the answer is “both”, you do not have an integration, you have a scheduled conflict. The day the same customer is edited in both places, one version gets discarded, and it will be the wrong one.
A split that tends to work: the CRM owns the relationship (contacts, history, opportunities), the ERP owns anything with fiscal weight (products, prices, orders, invoices), and the calendar owns time (who is busy when).
Once that is settled the rule is simple. Writes happen only in the owner. Everyone else receives and displays.
Events, not a general sync
The temptation is a routine that runs hourly comparing everything with everything. It works for a while and then becomes the most fragile process in the company: slow, hard to debug and perfectly capable of overwriting a recent edit with stale data.
What holds up is an event model. “Order approved”, “customer created”, “booking cancelled”. Each event triggers specific actions in the other systems. If one of them is down, the event waits in the queue and gets processed later, losing nothing and repeating nothing.
In practice you need three pieces: a receiver for notifications (the webhook the other system calls), a queue, and a processor that knows how to repeat an operation without doubling its effect.
Idempotency, the ugly word that saves the operation
Every integration will process the same message twice at some point. The other system resends because it did not get the acknowledgement in time, someone reprocesses the queue, the network hiccups.
If your processor is not ready for that, the customer gets charged twice or stock is deducted twice. The protection is simple: every event carries a unique identifier, and before acting you check whether that identifier has already been handled. It is half an hour of work that prevents the kind of error nobody can explain afterwards.
Log everything, including the payload
When an integration fails, and it will, the question is always the same: what exactly was sent and what exactly came back. Without a complete log you are left with speculation and finger-pointing at the other vendor.
Store, for each exchange: timestamp, endpoint called, payload sent, response received, status code and response time. Thirty days of history is plenty. It turns “the integration is playing up” into “at 14:32 the ERP returned a 500 on this call”, which is an entirely different conversation.
The middle layer that prevents lock-in
Wiring system A straight into system B looks economical and creates a problem for later. When either one gets replaced, the whole integration goes with it.
A layer in between, whether a small service of your own or a visual automation tool like n8n, receives on one side and delivers on the other, translating formats. Replacing the CRM then means rewriting one connector rather than the entire integration. And the people running the process can see the flow without opening code.
Start where it hurts most, and measure first
Do not try to integrate everything. Ask the team which repeated typing eats the most time and start there. Before automating, time it: how many minutes a day, how many people, at what error rate.
One client found three people spending forty minutes a day re-keying orders between the sales system and the ERP. That is two hours daily, ten hours a week. The integration paid for itself in five weeks, and that number only existed because it was measured beforehand rather than estimated afterwards.
Need this solved at your company?
A twenty minute call is usually enough to tell whether it makes sense, and you talk straight to the engineer who builds it.