- Support needs good data up front. Knowing which integration, which customer, which execution, and where in the process it failed determines whether a ticket needs to escalate.
- A defined process resolves many incidents in three steps instead of five. Customer-to-support-to-customer replaces the default customer-to-support-to-engineering-to-support-to-customer loop, but only when support has enough visibility to see what failed and why.
- Severity tiers matter less for their specifics than for being agreed on in advance. A P1 revenue-critical failure demands a response in minutes, while a P3 low-usage degradation can wait until the next business day.
- Thirty identical auth errors in a quarter aren't thirty separate problems. That pattern signals a single UX or onboarding issue, which only a postmortem process that tracks recurrence will find.
- An embedded iPaaS supplies the infrastructure but not the incident ownership model. Centralized monitoring, alerting, and replay only prevent the default escalation loop when a team has also decided who owns what and when.
The integration worked yesterday, but today, records aren't syncing. Your customer notices and opens a ticket. Support can't tell what's happening, so it it gets a Slack thread going with engineering. Forty-five minutes in, multiple people are still working on the answers to three questions: What broke? Who is affected? Who is fixing it?
Nobody's told the customer anything, because nobody has anything to tell them yet.
That's normal. Part of your product now depends on third-party APIs and customer configs that you don't completely control. That's reality. But what are you doing about it?
Failures will happen
APIs change endpoints. Auth tokens expire. A vendor renames a field, and your code (written against the old schema) chokes. Rate limits that didn't matter in the sandbox with one integration suddenly do with 20 customer instances running simultaneously.
Testing and monitoring can and do reduce failures. But there's nothing that will take them to zero. And, since you can't stop integrations from failing, the question becomes, "How fast can we detect it, understand it, and fix it?" The answer defines SaaS companies.
But what happens when something breaks?
When a customer reports that yesterday's invoices never hit its ERP, can your team quickly answer the following:
- Which integration?
- Which customer?
- Which execution?
- Did the data arrive, or fail before that step?
- Is it still happening?
- Is anyone else affected?
If support can't answer those, the ticket is escalated to engineering. An engineer traces the logs and finds the customer's credentials expired three days ago. Now you've spent engineering time to diagnose something that had nothing to do with your code. Do that across dozens of integrations and hundreds of customers, and every incident requires a start-from-zero investigation.
Why teams end up here
Most companies have proper incident discipline for their core app – alerting, on-call, and triage. That rigor tends to disappear for integrations, for a few consistent reasons:
- Build-and-forget – Shipping is treated as the finish line, when it's really the start of years of maintenance.
- No support visibility – Support lacks access to execution logs or credential status, so every issue gets escalated by default.
- Unclear ownership – Without a defined answer in advance, teams debate whose job it is instead of fixing it.
These result from treating integrations as one-off projects instead of product features with a full operational lifecycle.
What a defined process can do
Without a process, most incidents follow this path:
Customer → Support → Engineering → Support → Customer (resolution)
With the right visibility, many resolve like this instead:
Customer → Support → Customer (resolution)
This happens when support has enough context to see what failed and why, without looping in engineering. And when engineering is needed, it comes with details. At scale, the second resolution sequence is the difference between an integration program that grows with your customer base and one that overwhelms your engineering team with integration issues.
Defining the process
A structured response means specific people do specific things, on a defined timeline with everything agreed to before anything breaks. Here's what that looks like.
Detection
Find out before the customer does – alert on execution failures, elevated error rates, and jobs that should've run but didn't. Distinguish isolated noise (one customer, one retry that succeeds) from a systemic incident (every customer, same timeframe).
Triage
Not every failure needs the same response:
| Severity | Example | Response |
|---|---|---|
| P1 | Revenue-critical integration down for an enterprise customer | Minutes |
| P2 | Intermittent failure; partial data loss | Same business day |
| P3 | Low-usage integration degraded; workaround exists | Next business day |
The specific tiers and their definitions matter less than the fact that support and engineering agree on them.
Ownership
Give incidents tiered ownership like your product. Support handles configuration issues and expired credentials; an integration specialist handles mapping and workflow problems; engineering steps in only for code defects or breaking vendor changes. Don't simply route everything to engineering by default. That's what turns manageable volume into a mess.
Recovery and communication
Transient failures should retry automatically. Manual fixes should be re-playable without having the customer re-trigger anything. As a rule, customers will forgive failures far more readily than silence and a short, proactive update can change the entire tone of an incident.
Postmortem
It's time to close the loop. Why did it happen, and what changes were made to prevent it from recurring? Recurring errors are a signal. Thirty of the same auth errors in a quarter isn't thirty problems; it's a UX or onboarding fix that needs to happen. Track time-to-detect, time-to-resolve, and recurrence rates so you can fix broader issues as soon as possible.
Where embedded iPaaS fits – and where it doesn't
You can build this infrastructure yourself: logging, alerting, retries, credential storage, and more. Then you can maintain all of it, on top of the integrations themselves.
Or you can build on a platform designed for exactly this. An embedded iPaaS gives you centralized execution monitoring, configurable alerting, step-level logs, automatic retries, and replay – the infrastructure that makes support-level resolution realistic.
But a platform doesn't decide who owns an escalation, what counts as a P1, or who tells the customer what's going on. Those are organizational decisions your team owns. Great logs with no ownership model still get you the default resolution sequence. But now, you have better logs to sift through while everyone figures out whose job it is.
The platform scales, but the process still has to be decided.
A quick self-audit
- Do you find out about failures in minutes, or does the customer tell you first?
- Can support see what failed and why, or does everything escalate by default?
- Do you have severity tiers and response targets, as you do for product incidents?
- Is there a named owner for integration issues, or does it depend on who's around?
- Do incidents feed a postmortem, or does the same failure keep popping up?
If you answered "No" to several of these, that's a normal place to be. You now know what to do.
Reliability is no accident
You can't engineer your way to zero integration failures. However, you can engineer your response: fast detection, clear ownership, helpful prioritization, and direct communication. The whole process starts with treating integrations as product features, not side projects – with everything that entails for support, monitoring, and accountability.
Imagine one of your most important integrations breaks tomorrow, for a real customer doing real work. Do you find out before they do? Or is everyone in a Slack thread, figuring it out for the first time?
Prismatic's embedded iPaaS gives your team everything you need to build that process without reinventing the infrastructure.
Get a demo to see how your integration incident response could improve.
