Salesforce Integration Errors: Stop Finding Out Last

Salesforce integration errors are almost never loud. The sync between Salesforce and your billing system, your ERP, or your fulfillment tool does not crash with a red banner. It quietly stops delivering some of the records, and the first person to find out is a customer asking where their invoice is. My position: the integration itself is rarely the problem. The problem is that nobody in your business owns a list of what failed, and Salesforce does not give you one by default. That list is a small build, and it is the most valuable thing you can add to any integration you already have.

You find out from the customer, three weeks later

Here is how it usually goes. An Opportunity closes on a Tuesday. The integration is supposed to create the customer in the billing system. That day the billing system is rejecting requests for ten minutes during a maintenance window, so the call fails. Nothing in Salesforce looks wrong. The Opportunity is Closed Won, the rep moves on, the dashboard counts the revenue.

Three weeks later finance asks why there is a signed deal with no invoice. Someone opens a ticket. Someone else digs through logs, if there are logs. Eventually the record gets pushed by hand, and everybody agrees the integration is “flaky.”

It isn’t flaky. It worked the way it was written. It simply had no way to tell a human that one record out of four hundred did not make it, and no human was looking.

”It ran” and “it worked” are different facts

Most integrations are built to answer one question: did the automation run? The question the business cares about is different: did the other system end up with the right data?

Those two come apart constantly. The far end returns an error response, and the code that made the call carries on without treating it as a failure. A payload is accepted but a required field was blank, so the record lands half-formed. A job handles a batch of two hundred and nine of them are rejected. The token expired over the weekend and every call since Saturday has bounced.

In every one of those cases the automation ran. A debug log somewhere may even say so. What is missing is a record, inside Salesforce, that says this specific Opportunity did not reach billing, here is why, and nobody has dealt with it yet.

Salesforce sends an email, to one person

Salesforce does have built-in failure notifications. Read closely who gets them.

For flows, the documentation says that when a flow run fails, Salesforce sends an email “to either the admin who last modified the associated flow or the Apex exception email recipients”. For older Process Builder automation, Salesforce’s own knowledge article says the error email “goes to the administrator or user who last modified the process version that is failing”, and that there is no standard settings page for changing that. For Apex, unhandled exception emails go by default to the developer in the LastModifiedBy field of the failing class or trigger, unless you add recipients in Setup.

Think about what that means in a real org. The person who last touched the automation might be a consultant whose engagement ended in the spring. It might be an admin who left. It might be you, and the email is sitting under ninety other system notifications you stopped reading a year ago.

And notice the word unhandled. Well-written integration code catches its errors so one bad record does not sink the rest of the batch. That is the right design, and it also means no exception escapes and no email is sent. An error response from the other system is not a crash at all, it is just a reply your code has to choose to care about. The better the integration is written, the quieter its failures get, unless somebody deliberately builds the place where they land.

What you actually want: a failure inbox your ops team owns

So build that place. Not a log file, not an email rule. A list in Salesforce, owned by operations, where every failed handoff is a row that stays open until someone closes it.

Concretely, it is a custom object. Call it Integration Failure, or whatever fits your naming. Each record carries:

The record that failed, as a real lookup, so you can click through to the Opportunity, Order, or Account.
Which integration and which direction, so billing failures and shipping failures are separable.
What the other system said, in its own words, plus a plain-language reason your team can act on.
A category: will fix itself on retry, needs data corrected, or needs someone technical.
A status and an owner: New, In Progress, Resolved, Ignored, with a name against it.
When it failed and how many times it has been tried.

That’s the whole idea. A failure stops being an event that happened once in a log and becomes a piece of work with an owner. Because it is an ordinary Salesforce object, it gets list views, reports, dashboards, and assignment the same way a Case does. If your team already knows how to work a queue, they already know how to work this one.

The alert that goes to the right person

A list nobody opens is only slightly better than a log nobody reads. The second piece is routing, and it should follow the category rather than the technology.

A deal that failed to reach billing because the billing address is blank is not a technical problem. It goes to the account owner or to sales ops, with a message that says which field to fix. A burst of thirty failures in five minutes with the same authentication error is a technical problem, and it goes to whoever looks after the connection, once, as a single alert rather than thirty.

Three rules cover most of what you need:

Data problems go to the person who can fix the data, with the record linked and the missing piece named.
Systemic problems go to one technical owner, grouped, so an outage produces one notification.
Anything open longer than your tolerance escalates. If an invoice-blocking failure has sat untouched for a day, a manager hears about it.

Deliver it where your team already works: a Salesforce notification, a Slack channel, an email to a shared ops address rather than one human’s inbox. The point is that the destination is a decision you made, not an accident of who saved the flow last.

A re-drive button instead of a ticket

Now the part that changes how the work feels. Once a failure is a record, fixing it should be an action on that record.

Put a button on the failure record: Retry. Someone corrects the blank billing address on the Account, opens the failure, and clicks it. The same send that failed runs again with the corrected data. If it succeeds, the failure closes itself and stamps who resolved it and when. If it fails again, the record shows the new response.

Add a list-view version for the day the other system was down for an hour and sixty records piled up: select all, retry, watch them clear.

This is the difference between an ops team that can run an integration and one that can only report on it. Without the button, every failure is a ticket to someone technical. With it, the common cases are a two-minute fix by the person who already understands the customer. If you are designing an integration from scratch, the step-by-step custom integration build covers how to decide in advance which failures should retry on their own and which should wait for a human. The inbox is where the second kind goes.

The nightly check that catches what never errored

Everything above catches failures that announce themselves to your code. The most expensive ones don’t. The automation never fired because a record skipped the stage that triggers it. Someone changed a record in the other system directly. A deploy quietly altered the criteria.

There is no error to catch in those cases, so you go looking instead. A scheduled reconciliation asks a blunt question every night: which records in Salesforce should exist on the other side, and don’t? Every Closed Won Opportunity from the last thirty days with no billing ID. Every shipped Order with no tracking number written back. Every active customer whose plan in Salesforce disagrees with the plan the billing system reports.

Each mismatch becomes a row in the same failure inbox, flagged as found by reconciliation. Same queue, same owners, same retry button.

This is the piece I would build first if I could only build one. Error capture depends on the integration behaving well enough to notice its own problems. Reconciliation doesn’t trust the integration at all, which is exactly why it finds the things that have been wrong for months. It is close kin to the reports Salesforce can’t build natively: the data you need to compare lives in two places, so the comparison has to be built.

What changes once the list exists

The first change is that the conversation shifts from anecdote to count. “The integration is flaky” becomes “eleven failures last month, nine of them missing billing addresses.” That second sentence tells you the fix is a validation rule on the Opportunity, not a rebuild of the integration.

The second is that failures get found in hours instead of weeks, by your team instead of your customer. The invoice goes out a day late rather than a month late, and nobody outside the building knows there was a problem.

The third is that you can finally decide rationally about the integration itself. Plenty of teams are weighing a connector tool against a custom Salesforce integration with no data on how often either one drops records. A failure inbox with a reconciliation check gives you that number for whatever you run today, and it keeps working no matter which way you go. It is also the honest answer to “should we trust a custom Salesforce integration at all”: trust the one you can see into.

Why this never gets built, and what makes it small now

Nobody argues against a failure inbox. It doesn’t get built because it is the unglamorous second half of a project that was scoped as “connect A to B,” and the budget ran out when A connected to B. Going back to add it means finding a developer, re-explaining the integration, and paying for work that produces no new feature.

That math is what has changed. The pieces here are a custom object, some routing logic, a button, a scheduled job, and tests for each. That is well-understood Salesforce work, and it is the kind of thing an AI with build access to your org can do from a plain description of what you want, including reading the existing integration first to find where its failures currently go. With Sentinel, that work lands in a sandbox first with tests required, every change is logged with who made it, and a snapshot is taken before each deploy, so adding visibility to a live integration is something you can undo if it turns out wrong. If you want the detail on that, how AI gets write access to Salesforce covers it. The point for this post is simpler: the second half of the project is now something you describe, not a new statement of work.

Where to start

Start with reconciliation, on one integration, for one object. Pick the handoff where a miss costs real money, usually closed deals into billing. Ask for the list of records from the last ninety days that should be on the other side and aren’t. That list is free information, and it will tell you whether you have a small problem or a large one.

Then build the failure object and point the reconciliation at it. Then add capture on the integration itself. Then the retry button. Then alerts, once you know from real rows which categories actually occur, because routing rules written before you have seen your own failures are guesses.

Do not start by rewriting the integration. You don’t yet know what is wrong with it.

Pricing is flat per Sentinel and is covered on a short demo call.

Book a Demo Call and bring the name of the one integration you trust least. We’ll talk through what its failure inbox would look like.