How to integrate disconnected business systems

Start by mapping the systems you already have

Before any connector is configured, write down every system that holds business data, including the ones nobody officially approved. The shared spreadsheet counts. The inbox that receives enquiries counts.

For each one, note what it holds, who uses it, what enters it and what leaves it. The map is usually more revealing than expected: most stacks contain at least one system that everyone depends on and nobody owns.

Identify the source of truth for each data type

This is the decision that determines whether the rest of the work is straightforward or endless. For each data type, exactly one system is permitted to change it.

Disagreements are inevitable in practice; the point of naming an owner is that disagreements have a resolution rule instead of an argument.

Map how data moves today

Trace one real record end to end. A customer submits an enquiry: where does it land, who touches it, what gets typed again, how does finance eventually learn about it, and when does reporting see it?

Every arrow in that trace that is currently a person is a candidate connection. Every point where a value is retyped is a place where the two systems will eventually disagree.

APIs, webhooks and scheduled syncs

Three mechanisms cover most integration work. They are not competing options — a mature integration usually uses all three.

A rate limit is worth defining here too: most systems cap how many requests you may make in a period. Integrations that ignore this work in testing and fail on the first busy day.

One-way versus two-way synchronisation

One-way flow is the default and should be justified before it is abandoned. Data originates in one system, travels to another, and the receiving system never writes back.

Two-way synchronisation is required only when both systems genuinely originate changes to the same field. It brings three hard problems with it: deciding which version wins when both changed, preventing update loops where each system re-triggers the other, and handling messages that arrive out of order.

Avoid creating duplicate systems of record

The most common integration failure is subtle: a field is copied into a second system, someone starts editing it there, and within months two versions exist with no rule about which is correct.

The defence is discipline about direction. A copied field should be visibly read-only in the receiving system, or the receiving system should be the owner and the original should defer.

Integration versus replacement

Replacement is warranted in a narrow set of cases: the system exposes no usable interface, it duplicates the role of another system, its licensing makes integration impractical, or it is being retired anyway.

Otherwise, integrate. Replacement projects consume the budget and attention that would have connected four systems, and they carry migration risk that integration does not.

When a middleware or automation layer makes sense

Direct point-to-point connections are fine at small numbers. The cost grows quickly: connecting five systems directly can require up to ten separate connections, each with its own credentials, mapping and failure behaviour.

A layer in the middle changes that shape. Each system connects once, the mapping lives in one place, and monitoring covers everything rather than being reimplemented per connection.

It is not free. The layer becomes infrastructure that must be maintained, versioned and understood. The threshold is roughly the point where a third system needs the same data the first two already exchange.

Data normalisation and identifiers

Two systems rarely describe the world identically. One stores a full name, the other first and last. One uses country codes, the other free text. One has five pipeline stages, the other has seven.

Normalisation is deciding the canonical form and translating at the boundary. It is unglamorous and it is where most integration bugs originate — a date parsed in the wrong format or a status mapped to the wrong equivalent will corrupt data quietly for weeks.

Identifiers deserve particular care. Matching records by email address fails the moment someone changes theirs. Carry a stable identifier from the source of truth, store it in the receiving system, and match on it.

Security and permissions

Every integration is an account with access to business data, and it should be treated as one. Give each connection its own credentials rather than a shared administrator login, grant only the permissions the flow actually needs, and store secrets in a managed store rather than in a configuration field.

Credentials expire, and expiry is a leading cause of integrations that stop working with no visible error. Track expiry dates deliberately; do not discover them.

Visibility: know when the integration fails

An integration without monitoring is a liability that presents as an asset. It works, the team stops thinking about it, and the day it stops the business keeps operating on the assumption that data is still moving.

• Log every run with its identifier, outcome and duration.
• Alert on failure rate and on silence — a connection that has processed nothing all day may be broken.
• Hold failed records in a queue where they can be inspected and reprocessed.
• Route alerts to a named owner, not a shared channel nobody reads.
• Report reconciliation counts: records in one system versus the other.

A practical integration architecture

1. Map the systems, the data types and the people currently bridging them.
2. Assign one source of truth per data type and write it down.
3. Choose the direction of each flow, defaulting to one-way.
4. Pick the mechanism per flow — webhook for immediacy, API for detail, scheduled sync as a safety net.
5. Establish shared identifiers and the canonical form of each field.
6. Build the failure path before the happy path: retries, queue, alerts, owner.
7. Instrument it, then reconcile counts weekly until the numbers agree consistently.

That sixth step is the one most projects postpone and most regret postponing. It is covered in detail in error handling in automation, and the question of which coordination logic belongs in the CRM rather than the integration layer is answered in CRM vs workflow automation.

Mapping ownership, flow and failure behaviour before connecting anything is how we approach automation and business systems work — and it is the same architectural thinking behind the platforms we build.