Most integrations work beautifully on the day they're demoed. An order lands on the website, appears in the ERP, triggers a fulfillment task, and updates the customer record in the CRM. Everyone nods. The project closes.
Then, four months later, a customer calls about an order nobody in operations has ever seen. The website says it was placed. The ERP has no record. Somewhere in between, a message failed and nothing told anyone. Now your team is doing forensic accounting on a Tuesday afternoon, and every number in your reporting is suspect until they finish.
That gap — between "the integration works" and "the integration tells us when it doesn't" — is where most integration projects quietly fail. Here's how to close it.
Failure Is a Requirement, Not an Edge Case
When you connect two systems, you are not building one pipe. You are building a pipe plus a promise: every record that enters will either arrive or be visibly held for review. There is no acceptable third option, and "it disappeared" is the third option.
So when you scope an integration, ask for the failure behavior in writing before you ask about the happy path. What happens if the ERP is down for maintenance? What happens if a required field is empty? What happens if the same order is sent twice? If those answers aren't specified, they'll be improvised — usually as a log entry nobody reads.
Name Your Three Failure Modes
Failures aren't all the same, and treating them the same is why teams either drown in alerts or miss the important ones. In practice, almost everything falls into one of three buckets:
- Transient failures. The other system was briefly unavailable, timed out, or rate-limited. Nothing is wrong with the data. The right response is to try again automatically.
- Data failures. A tax code doesn't exist, a customer record is missing, a field is too long. Retrying forever won't help — a human needs to fix something, then replay the record.
- Logic failures. The systems disagree about reality: a duplicate, a record updated in two places at once, a sync order that doesn't make sense. These need a decision rule, not a fix.
Once you separate these, the design gets obvious. Transient failures get automatic retries with increasing delays. Data failures go to a queue a human owns. Logic failures need business rules you decide up front — for example, which system wins when both have changed.
Retries Only Help if Repeating Is Safe
Automatic retries are the cheapest reliability win available, but they have a prerequisite that gets skipped constantly: repeating the same message must not create a second record.
The fix is to give every message a unique identifier from the sending system, and have the receiving system check whether it has already processed that identifier before acting. If it has, it acknowledges and does nothing. That single design choice — repeatable without duplication — is what makes retries safe and what prevents the classic mess of duplicate invoices after a network hiccup.
Give Failures Somewhere Visible to Land
Every integration needs an error queue: a place where a failed record sits with the original data, a plain-language reason it failed, a timestamp, and a button to retry it after the underlying issue is fixed.
Notice what that requires. Not a log file. Not a developer with database access. A screen an operations manager can open, read, understand, and act on. If fixing a failed order requires filing a ticket with your integration partner, the integration isn't finished.
The replay capability matters as much as the visibility. Without it, someone re-enters the record by hand, and now you have manual work reintroduced into the automated process you paid to build.
Alert People Who Can Actually Do Something
Alerting fails in two directions. Too little, and problems age quietly. Too much, and the alerts get filtered into a folder nobody opens.
Route alerts by ownership: pricing and tax errors to finance, address and inventory errors to operations, authentication and connectivity errors to whoever maintains the systems. Group repeated failures into one notification rather than one per record. And set a rule for what happens when nobody responds — an unacknowledged error after a few hours should escalate, not expire.
Reconciliation Catches What Monitoring Misses
The most dangerous failures are the ones that never throw an error. A filter that silently excludes a record type. A field mapping that writes to the wrong place. A batch that stops halfway and reports success.
The defense is boring and effective: a scheduled comparison of both sides. Count the orders created in the website versus received in the ERP for the same period. Compare totals, not just record counts. Flag the differences to a human. Nightly is enough for most flows, and it catches the class of problem that no amount of error handling will surface on its own.
Ask These Questions About What You Already Have
You don't need a rebuild to find out where you stand. Ask your team, or your vendor, three things: Where do failed records go, and who looks there? What happens if the same message is delivered twice? How would we know if a hundred records went missing last month?
If the answers are vague, you have data risk sitting quietly in your operations — and it usually surfaces during a close, an audit, or a customer escalation.
Infraxio builds integrations between ERPs, CRMs, websites, and the rest of the stack with failure handling designed in from the start, not bolted on after the first incident. If you're not sure your current connections would tell you when they break, let's talk about what it would take to find out.