When an Integration Fails at the Edges

When two systems stop communicating, the integration is usually the first suspect.

That is understandable. One application was meant to send information to another, and the information did not arrive. The integration must be broken.

Sometimes it is.

Quite often, however, both applications are operating exactly as designed. The failure is somewhere around them.

It may be the account used to connect the systems. It may be a permission, field mapping, endpoint, network rule or local configuration. The first action may have succeeded, while a later step quietly failed. The workflow may even be technically complete while the person waiting for the result has received nothing useful.

That is what I mean when I say an integration has failed at the edges.

A note about the example

This article draws on patterns from completed technical work during my IT career. I have combined and generalised the details and removed all organisations, products, people, locations and dates.

It is an operational lesson, not a Lumomatics client case study.

The visible problem was simple

The original symptom looked straightforward: information that should have travelled from one system to another was arriving intermittently or not at all.

The affected workflow crossed several technical layers. There was a source application, an access and identity layer, a network path, configuration at both ends and infrastructure supporting the exchange.

At first glance, it looked like one component was failing.

Investigation showed that there was no single dramatic fault. Several smaller conditions were interacting:

• Connectivity was not consistently reliable.
• Configuration differed between parts of the environment.
• Access was not correct everywhere it was required.
• Some endpoints behaved differently from others.
• The infrastructure change needed to be deployed and verified across the complete workflow.

Each item was manageable on its own. Together, they produced an unreliable integration.

The eventual recovery involved reviewing the available evidence, correcting network and configuration controls, deploying the required component, fixing access and then testing the result from beginning to end.

The important part was not that one piece of technology had been repaired. It was that the complete business process worked again.

An integration is more than the connection

An integration diagram often looks like this:

System A → System B

The real workflow is closer to:

Trigger → identity → permissions → network path → interface → validation → destination → downstream action → human outcome

Every arrow is a possible failure point.

Consider an AI receptionist that answers a call and makes a booking.

The agent may successfully answer the phone and capture the caller’s details. But the actual business outcome could still depend on:

• The correct service being selected.
• The calendar accepting the appointment.
• The CRM creating or updating the right record.
• A confirmation message being sent.
• Staff being notified when human attention is required.
• Someone taking ownership if any of those steps fail.

An answered call is not necessarily a completed workflow.

This is why integration depth matters when assessing an AI voice agent. The interesting technology may sit in the middle, but the value is created at the edges: where a customer’s request becomes a booking, task, lead or clean human handover.

Every tool can look healthy while the workflow is broken

One of the more frustrating integration problems is when every supplier’s dashboard is green.

The phone service is available. The automation platform is running. The CRM is online. The calendar is responding.

Yet the workflow still fails.

Individual system health tells you whether each component is operating. It does not necessarily tell you whether the complete journey is working.

For example:

• A form submission can receive a success response while the CRM rejects one of its fields.
• A booking can be created while the confirmation message fails.
• A CRM record can exist without being assigned to anyone.
• An AI agent can complete a conversation while escalation instructions go to an unattended destination.
• An automation can retry repeatedly and create duplicate work.
• A credential can remain valid but lose access to a particular resource.

None of these necessarily produces a large, obvious outage. Instead, the business sees missing leads, incomplete bookings, duplicated records or customers who have to call again.

Small failures at the edges become operational friction.

Start with the outcome, not the software

A useful investigation starts by defining what success looks like in business terms.

Not:

The integration returned a successful response.

But:

The customer’s request appeared in the correct system, contained the required information, reached the right person and produced the expected follow-up.

That distinction changes how the workflow is tested.

Rather than asking only whether two systems can connect, I would ask:

1. What event starts the workflow?
2. Which systems, accounts and permissions does it depend on?
3. What information must pass between them?
4. How do we know each step succeeded?
5. What happens when information is missing or invalid?
6. Who is notified when the workflow cannot continue?
7. What does the customer experience while that happens?
8. Who owns the recovery?

This is one reason Lumomatics starts with a Workflow Clarity Audit when the process is unclear. Automating a poorly understood workflow usually makes its weaknesses faster and harder to see.

Test one boundary at a time

When an integration has several dependencies, changing everything at once makes diagnosis harder.

A more dependable approach is to test each boundary separately.

Can the originating system produce the correct event? Can the connecting account authenticate? Does it have the right permissions? Can information travel through the expected network path? Does the receiving system accept the data? Does the next action occur? Is the final result visible to the person who needs it?

Evidence matters here.

Logs, timestamps, transaction identifiers and controlled test records help establish how far a request travelled. They turn “the integration seems unreliable” into a more useful observation, such as “the request reached the destination but failed validation before creating the record.”

The purpose is not to produce an impressive collection of diagnostic information. It is to narrow the problem without guessing.

Test the awkward paths before customers find them

The normal path is usually the easiest one to demonstrate.

A clean record enters the workflow. Every required field is present. Each system is available. The automation succeeds.

Real work is less tidy.

Before relying on an integration, test what happens when:

• A required detail is missing.
• A customer already exists.
• Two similar records are found.
• The destination is temporarily unavailable.
• A request times out after being submitted.
• A credential expires or loses permission.
• A field format changes.
• The same event is received twice.
• A human needs to take over.
• Part of the workflow succeeds and part fails.

The failure path should be designed, not left to chance.

That does not mean every small business needs an elaborate technical monitoring platform. It means important failures should become visible, fall back safely and have a named owner.

Ownership is part of the integration

Automation can transfer information, create tasks and send alerts. It cannot resolve an exception if nobody is responsible for acting on it.

A dependable workflow answers a few plain questions:

• Where does a failed item go?
• Who sees it?
• How quickly do they need to respond?
• Can they recover it without specialist assistance?
• How will they know whether the customer has already been affected?

Without those decisions, the automation is incomplete.

This is particularly important for customer-facing workflows. If an AI receptionist cannot complete a booking, it should not invent an answer or leave the request suspended. It should collect the right information, explain the next step and create a usable handover.

The same principle applies to broader managed AI employee workflows. A useful AI system needs boundaries, escalation rules and an operating process around it. The model is only one component.

Good integrations are maintained

An integration that worked at launch can still fail later.

Applications change. Permissions are tightened. Fields are renamed. Staff members leave. Suppliers update interfaces. Business processes evolve while the automation continues following the old rules.

That makes monitoring and periodic review part of the design.

For an important workflow, I want to know:

• Whether it is still completing successfully.
• Whether exceptions are increasing.
• Whether information is reaching the right destination.
• Whether people are using the handover process.
• Whether changes to connected systems have introduced new risks.
• Whether the original automation is still worth maintaining.

This is also why the cheapest-looking integration is not always the lowest-cost option. Setup is only part of the work. Integration depth, testing, monitoring, change control and recovery all influence the real first-year cost, as discussed in the Lumomatics AI receptionist cost guide.

A practical integration checklist

Before connecting two business systems, confirm that you can answer these questions:

• What business outcome must the workflow produce?
• What are all the systems and dependencies between the trigger and that outcome?
• Which account owns the connection?
• Are the required permissions documented?
• What information is essential, and how is it validated?
• How are duplicates, missing details and partial failures handled?
• Is there a safe human fallback?
• Who receives failure notifications?
• Who owns recovery?
• Can the complete journey be tested after a system or configuration change?
• Is there enough evidence to diagnose a failure without exposing sensitive customer data?

If those answers are unclear, the workflow is not ready to be treated as dependable.

The lesson

The lasting lesson from that earlier integration recovery was simple: do not stop at the component that appears to be failing.

Follow the complete journey.

Check the boundaries between systems, the permissions around them, the infrastructure beneath them and the people waiting at the other end. Then verify the business outcome—not just the technical response.

Good integration should be boring. Information arrives where it is needed. Exceptions are visible. People know what to do next. Customers do not need to understand the machinery behind it.

If your business has accumulated forms, inboxes, calendars, spreadsheets and disconnected software, a Workflow Clarity Audit can map the full process and identify where a sensible automation would help—and where improving the handover may matter more than adding another tool.