Salesforce never tells you.

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.

Many hands, one system

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.

The org is a noodle soup where everything is related to everything, and a small change here has a large consequence somewhere else. Checking has not kept pace with changing. That gap is the whole problem.

Apex coverage is a comfort blanket

"We're at 75% coverage" is said in deployment reviews like a seatbelt clicking into place. Everyone exhales. Ship it. Here is the uncomfortable part: 75% code coverage tells you your Apex runs. It tells you nothing about whether your business still works. Coverage proves a method returns the value the test expects. It does not prove a rep can convert a lead, build a quote, and clear approval across your real screens, flows, packages, and permissions. The green checkmark is not lying. It is answering a different question than the one you needed answered.

Full regression is extremely hard to build by hand

Covering a system means imagining everything that could fail: the positive case, the negative case, the boundary, the unknown, the handoff between two people with different access. A person has to visualize all of it in their head and then build each one, and the building has been slow, script-heavy, and brittle. So teams cover what they thought of, at the one moment they were paying attention, and the loop closes: there is never time to build the regression, so they keep building features until something suddenly happens.

Release-time testing misses it anyway

Silent breakage does not respect release windows. A package updates on its own schedule. A sandbox refresh wipes configuration. A seasonal release changes behavior nobody announced. The process that mattered broke on a Tuesday, and the next scheduled check is three weeks out.

The Friday deploy

Anyone who has pressed Deploy in Salesforce knows the feeling: the fear of the phone call from an internal user or a customer. Monday passes. Tuesday passes. Nothing happens, so everyone believes it went fine. Two weeks later a comment leads to the discovery that something has been growing, unnoticed, the whole time. This is the silent risk.

The stakes

Errors carried into production tarnish the company's name, cost money, expose data, and create legal exposure. The CEO would love to be told "we are releasing today and everything will be fine," and the honest owner of a Salesforce estate often cannot say it, because they do not know. There are too many things that could go wrong, and no reliable way to find them first.

The tools so far

Cumbersome, hard to use, slow to implement. They needed script writers, they broke when a screen moved, they passed when the clicking finished, they replayed one identity with stale data, and they were expensive enough that most teams did without. The market has treated "did the button still work" as the product, and that is the wrong question.

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.