CRM Integration and a Data Flow You Can Maintain

Almost every business that has run for a few years shares the same problem: its data is scattered. Leads sit in a messaging app, sales are recorded in a spreadsheet, payments live in another system, marketplace orders somewhere else again. Every report combining them becomes a project, and a simple question like "what were customers from last month's ads worth" takes half a day to answer.

The first temptation is connecting everything to everything. The usual result is an integration maze nobody dares touch, where every breakage becomes an investigation. This article lays out a more durable approach: naming a source of truth, defining data contracts, choosing the right integration pattern, and keeping the whole thing maintainable.

The first step is not choosing a tool

Before touching any tool, answer one question for each type of data: which system has the right to be its source of truth?

Customer data, for instance, may appear in five places. But only one may be treated as correct when two disagree. Settling that early resolves most future arguments and determines the direction data flows.

Data type	Usual source of truth
Customer identity and contact	CRM
Sales status	CRM
Catalogue and pricing	Product system / ERP
Payments and invoices	Finance system
Website content	CMS
Lead traffic source	Site form, stored into CRM

The accompanying rule: data may only be edited in its source of truth. Other systems may display a copy, but must not be where people edit it. Breaking this rule is the number one cause of contradictory data.

Data contracts: agree the shape before connecting

Brittle integrations almost always grow from assumptions nobody wrote down. One system sends phone numbers with a leading zero, another expects a country code. One uses dates with a timezone, another does not. Everything works until one day it does not.

A data contract is a written agreement about the shape of data in transit. It need not be a formal document; one page is enough, as long as it covers four things.

1. The field list with types and whether each is required.
2. Agreed formats for the risky ones: phone numbers, dates and timezones, currency, and unique identifiers.
3. What happens with invalid data — rejected, stored with a flag, or sent to a review queue.
4. Who may change this contract and how changes get announced.

Normalise in one place

If phone numbers need normalising — all stored with a country code, say — do it in exactly one place, as close to the entry point as possible. Normalising inside every integration means every integration has its own version of the rules, and sooner or later all three will differ.

Three integration patterns and when to use them

Push on event

The source system sends a notification as soon as something changes. Fast and efficient, but it needs failure handling: what happens when the receiver is down? This pattern suits events needing immediate reaction, such as a new lead arriving.

Periodic pull

The destination system checks for changes every few minutes or hours. Simpler and more resilient, but with a delay. Suits data not needing instant reaction, such as catalogue sync or daily reports.

Scheduled file export

Data is sent as files on a fixed schedule. It looks old-fashioned, but it is the easiest to audit and the easiest to rerun when something goes wrong. Suits financial data and reconciliation.

Most businesses need a combination rather than one pattern for everything. Choosing a pattern per data type, rather than per system, usually produces a far simpler design.

Good integration is not the most sophisticated one. It is the one the next person can understand at eleven at night when they have to fix it.

Treating failure as normal

Every integration will fail. Networks drop, destination systems go into maintenance, rate limits get hit. What separates calm integrations from troublesome ones is whether failure is treated as a normal event with a plan already in place.

• Retry with increasing delays. Retrying instantly and repeatedly often makes things worse.
• Cap the retry count, then move the item to a queue for human review.
• Make replays safe. Resending the same data must not create duplicates. Unique identifiers from the source system guarantee this.
• Log every failure with enough detail to trace it back.
• Alert a person, not just a log nobody opens.

The third point is the most frequently missed and the most troublesome when ignored. An integration that is not replay-safe creates duplicate customer records, and cleaning those up costs far more than preventing them.

Unique identifiers: the small thing that saves everything

Most cross-system data chaos traces back to one simple unanswered question: how do two systems know they are talking about the same customer?

Matching on names almost always fails — people write their names inconsistently, with titles, with abbreviations. Matching on email is better, but one person can have several addresses, and one address can be shared within a company. Phone numbers are more stable but come in wildly varying formats.

The durable solution is assigning your own identifier in the source of truth, then storing that identifier in every other system as a reference. Other systems may keep their own internal numbers; what matters is one column holding the source-of-truth identifier. Matching then never depends on guessing.

Handling data that is already messy

If duplicates have already accumulated, do not attempt to clean everything at once. The order that usually works: first stop the cause of new duplicates — normally a non-replay-safe integration or a form without checks — then clean up the old ones. Cleaning while the tap is still running is work that never finishes.

For the cleanup itself, work in stages by value: start with active customers, then customers from the past year, then the rest. Some old records may not be worth cleaning at all, and admitting that beats deferring the project forever.

How many connections is reasonable

The number of connections grows much faster than the number of systems. Five directly interconnected systems can produce ten connections, and each one is something that can break.

So as systems accumulate, consider routing data through one central point rather than connecting everything directly. That central point need not be expensive tooling — it can be as simple as one database or one small service that receives and forwards. The benefit: each new system connects once, and normalisation rules live in one place.

Two-way sync: only when genuinely needed

Two-way synchronisation sounds ideal and is almost always more complicated than expected. Once two systems may both change the same data, a question appears with no automatic answer: if both change at nearly the same moment, which wins?

Before committing to two-way, check whether one-way is enough. In practice, most needs are met by one-way plus a read-only view on the other side. If two-way is genuinely required, define the winning rule explicitly — usually per field rather than by timestamp — and log every conflict for review.

Testing integrations before trusting them

A new integration should be tested with three kinds of case, not only the normal one.

1. Normal cases — complete, correct data. Always tested, rarely the problem.
2. Edge cases — names with apostrophes, very long addresses, oddly formatted phone numbers, zero values, empty fields.
3. Failure cases — destination down, slow responses, rejected data. Test by deliberately switching one side off.

The third group is skipped most often and matters most. An integration never tested under failure will demonstrate its behaviour for the first time in production, usually at the least convenient moment.

Security and access

Integrations move customer data, so they move risk too. A few basics that are cheap to follow and expensive to ignore:

• Credentials never live in code or get sent through chat. Store them in a secrets manager and rotate them.
• Grant minimum permissions. An integration that only needs to read must not have delete rights.
• Send only the fields needed. Sending a full customer record to a system that only needs a name adds risk with no benefit.
• Log who accessed what, particularly for contact data.
• Separate test from production. Testing with real customer data is a habit that eventually causes an incident.

A realistic work sequence

Connecting everything at once almost always ends half-finished. This order delivers benefit sooner at lower risk.

1. Unify where leads arrive. All forms, messages, and calls flow into one place with a channel marker.
2. Connect sales status. So leads can be traced to won or lost, with their source known.
3. Connect payments. Closing the loop from lead to money received.
4. Then connect the rest — catalogue, inventory, reporting — as genuine needs appear.

The first three already make almost every marketing question answerable, including the ones covered in our marketing ROI guide.

Documenting so it can be handed on

Integrations are the part of a system most often built by one person and least often documented. When that person leaves, what remains is a set of connections running with nobody knowing what is inside them.

Sufficient documentation need not be long. One page per integration covering five things: which system to which system, what data moves, when it runs, what happens on failure, and who owns it. Add one simple diagram showing the direction of arrows between systems, and a new person can work without reading code.

Store that document alongside other operational documents, not inside a code repository only developers open. The person who most needs it during an incident is usually not the person who wrote the code.

When an integration is not worth it

Not every connection deserves to exist. Before starting, calculate the time genuinely saved and compare it against the cost of building and maintaining it for a year. Situations that usually do not justify the effort:

• Data that moves a few times a month. Copying ten rows by hand monthly is cheaper than maintaining a connection forever.
• Systems due to be replaced soon. Building an integration to a system with six months left is work thrown away twice.
• A need that is really reporting, not synchronisation. If the goal is only seeing combined numbers, a scheduled export into one spreadsheet is often enough.
• Processes that are not yet stable. Integrating a workflow that changes monthly means rebuilding the connection monthly too.

Declining to build an integration that is not worth it is not laziness; it is an architectural decision. Every connection not built is one thing that will not break, will not need explaining to newcomers, and will not need repairing when the system on the other side changes.

Alternatives that often suffice

Before building a direct connection, consider two middle paths. First, a scheduled export into shared storage — simple, auditable, and enough for reporting without the risk of writing back into another system. Second, deep links between systems: rather than copying customer data into a second system, store a link that opens the original record. That removes an entire class of synchronisation problems at the cost of one column.

Signs your integrations are in trouble

• Someone routinely copies data by hand "because it is faster".
• Reports from two systems produce different numbers and nobody can explain why.
• Nobody knows which integrations are still running and which are dead.
• A small change in one system causes breakage somewhere unexpected.
• Duplicate customer records grow every month.

The first sign is the easiest to ignore and the most informative. Persistent manual copying means there is a need the existing integrations have not met.

In summary

Name the source of truth before touching a tool. Write a data contract, even a one-page one. Choose an integration pattern per data type, not per system. Treat failure as normal and make replays safe. Avoid two-way sync unless it is genuinely required. Then work in order: leads, sales, payments, and only then the rest.

Want your business data flow mapped and tidied? Get in touch with our team.