Nobody tells you when a Salesforce process breaks.
Ask a Salesforce team whether every critical process in their org works right now. Almost nobody can say yes with confidence, and the honest ones will tell you so. That is not carelessness. It is the shape of the platform.
Failure without an error
When a deployment breaks an approval rule, nothing goes red. No alert fires. The org keeps accepting records, keeps routing cases, keeps closing opportunities. From the outside everything looks exactly as it did yesterday.
The failure surfaces later, and never as a failure:
- A discount that should have needed Finance approval went out without it
- A support case that should have escalated sat in a general queue for three days
- A won deal created two orders instead of one, and finance found it at month end
By the time anyone connects those to a change made weeks earlier, the damage is done and the trail is cold.
Everyone changes the same org
The other half of the problem is how many hands touch a Salesforce org. Administrators change configuration. Developers ship code. Consultants deliver projects. Managed packages update themselves. Salesforce ships three major releases a year. Increasingly, AI tools make changes that used to take a week take an afternoon.
Every one of those can affect a process nobody was watching, and none of them can reasonably be expected to know what every other team depends on. Checking has not kept pace with changing. That gap is the whole problem.
Why release-time testing misses it
Most teams check at release time, which catches the things they thought to check, at the one moment they were paying attention. But silent breakage does not respect release windows. A managed package updates on its own schedule. A sandbox refresh wipes configuration. A seasonal release changes behaviour nobody announced. The process that mattered broke on a Tuesday, and the next scheduled check is three weeks out.
What would actually help
Not more tests. A short list of the processes you genuinely cannot afford to lose, checked continuously, by something that re-performs the whole process rather than replaying clicks, and that stays quiet while everything holds.
The point is not to find every bug. It is to never again learn about a broken business process from a customer.