Article
Most failed integrations are not technical failures — they are a person who was on vacation. The hard part of fixing it is not the code, it is agreeing what the statuses mean.
Most failed integrations are not technical failures. They are a person who was on vacation.
Here is the pattern. Two systems need to share information. Rather than connecting them, the organization connects them through a human: someone checks system A, and when something reaches a particular state, they enter it into system B. This works. It is flexible, it handles exceptions intelligently, and it requires no project.
It is also an integration whose uptime depends on somebody's attention, and attention is the least reliable component in any architecture.
We saw a clear version of it recently: a single record entered by hand into three separate systems as it moved through its lifecycle. Once at first contact, again when it reached the operational system, and a third time at the point of scheduling. Same information, three keyboards, three opportunities for the systems to end up disagreeing about a name, a date or a reference number.
Each of those re-entries had a reason. The systems were bought at different times by different parts of the business to solve different problems. No one ever decided that a person should be the integration layer; it was simply what remained once everything else was decided.
The time is the obvious cost and the least interesting.
Divergence. Three manual entries of the same information produce three records that are nearly identical. Nearly is the problem. A transposed digit in one system and matching becomes guesswork.
Latency you cannot see. Data moves when somebody gets to it. On a normal day that is fast. During a backlog, over a holiday weekend, on the day someone is out sick, it is not — and nothing reports this, because the queue is in a person's head.
Exceptions become invisible. When a human handles the handoff, they also handle the oddities, silently. Nobody knows how often the odd case occurs because it never gets logged. You find out when you try to automate it.
It does not scale in the way you need. Twice the volume means twice the entry work. The thing you wanted to grow is bounded by the thing you never designed.
The alternative is to let the record's own state drive its movement. When a record reaches a given status, the integration acts. No one decides it is time; the data's condition decides.
This sounds obvious and has one implication that makes it hard: your systems have to agree on what the statuses mean.
That is not a technical problem. It is an organizational one, and it is where this work actually happens.
Start with the vocabulary, because the vocabulary is usually the first thing to disagree.
In a healthcare estate we worked on, a person arrives in the commercial systems as a lead, becomes a customer, and is only called a patient once the record passes into the clinical system and enters the revenue cycle. Three names for one human being, each correct inside its own system, each belonging to a team that would be confused by the others.
None of that is a defect. Sales genuinely is working with a lead; the terminology reflects what that team is doing. But an integration cannot be built on three vocabularies that nobody has mapped to each other, and no amount of engineering skill substitutes for the conversation where somebody writes down that this thing here is that thing there.
What we did first
We mapped how data actually flows, drew each workflow out, and validated every one of them with the team that owns it — not reviewed, validated: the people who do the work confirming that the diagram matches what happens. Alongside each workflow sits a field mapping document tying the fields in one system to the fields in the next.
This is unglamorous and it is the entire foundation. An integration built without it will work in testing and produce confidently wrong data in production.
The second discovery is that systems have far more status values than they have meaningful transitions.
Each system carries a long list of states, accumulated over years by whoever configured it for whoever asked at the time. Only a handful of them represent a moment when something should move. The work is identifying which.
The clearest example from that estate: scheduling is not the trigger for the financial systems. It feels like it should be — the appointment is in the calendar, the commitment exists, the record is complete. But revenue cycle management does not begin when care is scheduled. It begins when care has been provided. A scheduled appointment can be canceled; a delivered service is a fact. Pushing data into finance at scheduling means pushing records that may be withdrawn, which is how an integration generates reconciliation work rather than removing it.
Picking the right trigger is less about system design than about understanding where the business considers something to have actually happened. Those are different moments, and the second one is the one that matters.
Every integration gets built for forward motion and every real process includes reversal. Records are canceled, rescheduled and corrected, and an integration that only moves one way will produce wrong data confidently.
Work through what reversal actually means in your process, because it is rarely just an undo. In the healthcare example: a lead converts to a customer, becomes a patient when care is scheduled, and then the appointment is canceled because the person received care at a different facility. Handled naively, that leaves a stale patient record in the clinical system and nothing anywhere else.
Handled properly, the reversal flows back to the commercial system, where the record returns to the sales team as a lead they can follow up — someone who wanted the service, did not receive it here, and is worth a conversation. The same event is either a piece of data decay or a sales opportunity, depending entirely on whether anyone designed the path backwards.
Answer these before you build anything
Which system is authoritative?
For each field, one system owns the truth. Without this you get two systems overwriting each other.
What happens when it fails?
A human integration layer notices failure. An automated one does not unless you build that in — and it has to tell someone who can act, not a log nobody reads.
What about the exceptions the person was handling?
Those still exist. They are now visible, which is an improvement, but they need somewhere to go.
The point
If a process depends on somebody noticing that it is time to copy information from one system into another, that is not a workflow. It is an integration with a person standing in for the code, and it fails in the ways people fail rather than the ways systems do.
Let the status move the data. The hard part is agreeing what the statuses mean — and that conversation is worth having whether or not you ever build the integration.
Filed under
Written by
Lead Engineer, Modern Signal
Modern Signal's integration practice, building the connections between systems that people were standing in for.
Where this came from
A healthcare provider
A healthcare provider's technology estate had grown by addition, with every business unit solving its own problem. We took over running it, then rebuilt what duplication had made expensive.
Read the case study: Entered once, not three times — 70% faster RCM workflows and 35% off licensing~70%
Faster revenue cycle workflows
Tell us what it looks like today and we will tell you what we would look at first.
Nothing here is required except an email address and enough detail to reply usefully. The more you tell us, the better the first answer.
