Integration problems are usually process problems
Connecting two tools is easy compared with deciding what should happen when the real business rules get involved.
Most integration work is not hard because data needs to move from one system to another.
It is hard because the business has to decide what should happen when the data is late, incomplete, duplicated, wrong, or different from what the process expects.
The connection is only one part
A simple integration might sound like this:
When an order is paid, create a job.
The real version usually needs more detail:
- What counts as paid?
- What happens if the customer already exists?
- Which fields are required before a job can be created?
- Who is notified when something fails?
- Where is the error recorded?
- Can the step be retried safely?
Those decisions matter more than the connector.
Map the exception path
Good integrations do not assume everything works.
They define what happens when it does not. Failed steps should be visible, recoverable, and assigned to the right person. The system should not quietly drop work or create duplicates that the team finds later.
If the exception path is unclear, the integration will feel unreliable even if the technical connection works.
Protect the source of truth
Before connecting tools, decide which system owns each piece of data.
Customer details, stock status, job progress, payment state, and reporting numbers should not all be edited everywhere. The integration should move information in a way that keeps ownership clear.
Better integrations feel boring
The best integrations do not feel clever. They feel calm.
The right data moves at the right time. Failed steps are visible. The team knows which system to trust. Nobody has to ask whether the work made it across.
