A customer calls and gives a new address. The service rep updates it in the system in front of them. A week later a delivery goes out to the old address, because the distribution system never heard about the change.
Nobody made a mistake. The rep did exactly what was asked. There were simply two answers to the question "where does this customer live", and only one of them was updated.
This is not an isolated glitch. It is what happens when an organisation runs more than one system without deciding which of them has the final say.
How two versions of the same reality come about
Almost no organisation ever chose to split its customer data. It happened on its own, in stages.
The sales system came first. Then a service tool was added, because sales could not handle support enquiries. Later a distribution system joined, and alongside it the collections department ran a spreadsheet. Each one was chosen at the time as the right decision for a real need.
But every one of those systems created a customer record. And from the moment there are two records, there are two truths.
The symptoms are familiar. The same customer appears twice with a different spelling. The status is "closed" in one system and "in progress" in another. Someone sends a report and someone else sends a contradicting one, and both are right relative to the source they pulled from.
Then comes the stage where the organisation stops trusting its own numbers. A manager asks for a figure, receives it, and checks it by hand before passing it on. That manual check is the real cost, and it never shows up on any report.
Exporting a file is not integration
The first common answer is an export. You pull a file out of one system, load it into the other, and take it from there. It works, and it is also what makes most organisations think they have solved the problem.
They have not. An export is a snapshot, and integration is a live connection. The difference shows up in three places:
- In time. A file represents the moment it was created. From the next second onwards it is out of date, and every decision based on it is based on the past.
- In direction. An export flows one way. An update made on the receiving side never travels back to the source, so the gap between the two actually widens the more the system is used.
- In errors. A file that only half loaded tells nobody. Three rows dropped, a thousand went through, and nobody knows which three.
A real connection between systems works differently. It reacts to an event the moment it happens, it knows how to send an answer back, and it knows how to shout when something fails.
Three questions that decide whether the connection holds
Before a single line of code is written, three decisions determine whether the integration lasts a year or falls over in the first month.
Who is the source of truth for each field. Not for the whole record, for each field separately. It is entirely possible that the address is set by the distribution system, the payment method by collections, and the ticket status by the service system. What you cannot have is two sides both believing they own the same field, because then every update overwrites the previous one in turn and the system looks like it is losing its mind.
What happens when the other side does not answer. A system goes down, a server is under maintenance, a network drops. The question is not whether it will happen but what happens when it does. A connection built properly holds the event in a queue, retries, and reports when it could not get through. A connection built quickly simply loses the update in silence.
How you identify that it is the same entity. Two systems holding a "David Cohen" are not necessarily holding the same person. You need a stable identifying key that travels between the systems, not a match on name. It is the dullest technical detail on the list, and it is the one that sinks the most projects.
API and webhook: who asks whom
These two words come up in every conversation about connecting systems, and the difference between them is simpler than it sounds.
An API is an interface that lets one system ask something of another. You ask, it answers. If you want to know that something has changed, you have to keep asking.
A webhook reverses the direction. Instead of you asking, the system tells you the moment something happens. You do not check whether the customer updated their address, you receive a notification that they did. The standard that describes interfaces of this kind, the OpenAPI Specification, defines both patterns side by side, which is why a vendor that publishes a conformant document saves you half the mapping work.
In most organisations the right answer is a combination: webhooks for events that need an immediate response, and a full periodic sync running in the background to catch whatever fell between the cracks. The second layer is the one people skip, and it is the one that prevents a slow, silent drift in the data over months.
When we build integrations and APIs, we start by mapping the fields and the sources of truth and only then go near the code. In most cases that map is also the first document that shows an organisation how much duplication it actually has.
What to do when the legacy system has no interface at all
This is more common than it seems. The system holding the most important data is usually also the oldest one, and it often has no API whatsoever.
That is not the end of the road. You can read directly from the database in read-only mode, build a middle layer that exposes a modern interface on top of the existing system, or pull the data out on a scheduled job and feed it onwards. The legacy system carries on working exactly as before, and a layer is built above it that talks to everything else.
This is the point where we are in no hurry to replace anything. A business that swaps out a core system to solve a communication problem has paid a price far larger than the problem. Usually it is better to build custom systems around what already exists, and only if the system itself is already limiting the business to approach an Access upgrade as a separate, planned step.
Frequently asked questions
How many systems is too many?
There is no number. An organisation with seven well connected systems runs better than one with two that do not talk. The question is not how many systems you have but how many times the same piece of data is typed in by hand on an ordinary working day.
Does integration replace the existing systems?
No. An integration is built on top of what already works and leaves every system in its role. That is exactly why it is usually the cheaper and faster move compared with an upgrade, and in many cases it pushes the need for one back by years.
What happens when an external vendor changes its interface?
It happens, which is why a connection is built with a translation layer of its own instead of binding directly to the other side's structure. When the vendor changes something, you fix one place rather than the whole system. Monitoring that raises an alert on failure is part of the build too, not an add-on.
How do you know the connection is really working?
By how much double keying has disappeared, and by how often someone still checks a figure by hand before presenting it. If people are still cross-checking numbers between two systems after the connection is live, it solved the transport and not the source of truth.
The problem is almost never that there are a lot of systems. The problem is that none of them was ever declared the one that decides, so all of them decide. Once there is an explicit answer to who owns each field, what happens when one side does not answer, and how you tell that it is the same entity, the connection itself turns into the easy part of the story.
The question is no longer whether your systems talk to each other. The question is which of them says the last word.
For a solution tailored to your business:
Get in touch by leaving your details for a callback, give us a call, or reach us on WhatsApp
We would be glad to help!