Why Salesforce Automated Testing Still Leaves You Exposed Before a Major Release

Salesforce is one of the best-tested enterprise platforms in existence. Apex unit tests are a deployment requirement. The ecosystem of testing tools — Provar, Copado, Selenium-based frameworks, and Salesforce's own testing infrastructure — is mature and capable. Development teams building on Salesforce have more automated testing support than almost any other enterprise platform.

And yet Salesforce releases continue to cause production incidents at enterprise organisations. The pattern is consistent: automated testing passed, something unexpected happened in production.

The explanation isn't that automated testing is bad. It's that automated testing and UAT are solving different problems.

What automated Salesforce testing actually validates

Apex unit tests verify that code executes correctly against its own logic. They don't test the org — they test the code. When you deploy with 75% code coverage, you've confirmed that three-quarters of your Apex logic runs without erroring. You haven't confirmed that your users can do their jobs.

End-to-end testing tools like Provar and Selenium-based frameworks go further — they can simulate user journeys through the UI. These are valuable. Their limitations are:

• —They test the journeys they were programmed to test — and Salesforce orgs at enterprise scale have more permutations than any test suite covers
• —They run against a test environment that may not perfectly mirror your production org's configuration, data, and active users
• —They can't make judgment calls — if an unexpected result appears, automated testing records it as a pass or fail; a human tester investigates it
• —They don't account for the institutional context that shapes how real users interact with your org

Where Salesforce releases fail in production

After thirteen years of running UAT on enterprise Salesforce implementations, the failure patterns are recognisable. The issues that make it to production are almost never caught by automated testing — they're the ones that require context to find.

Permission set conflicts across profiles

Salesforce's security model layers profiles, permission sets, and permission set groups. An automated test verifies that a named profile has access to an object. What it doesn't catch: a permission set assigned to a subset of users in that profile that creates a conflict, or a new permission set that silently overrides a restriction that compliance depends on.

UAT catches this because testers log in as users — not as system administrators — and attempt to do their actual jobs. The conflict surfaces when a compliance-sensitive field appears editable to someone who shouldn't be able to touch it.

Data migration integrity at the record level

Data migration validation in automated testing compares field-level outputs against expected values. It doesn't validate whether the migrated data makes business sense. A contact record with a null phone field passes validation. A contact record associated to the wrong account — because the matching logic handled a naming convention inconsistency incorrectly — passes validation too. Neither is found until a sales rep tries to use it.

Flow and Process Builder interactions

Complex Salesforce orgs accumulate automation over years. Flows trigger on record changes. Process Builder rules fire on field updates. Apex triggers run on DML operations. These interact with each other in ways that are difficult to anticipate and nearly impossible to fully model in an automated test suite.

The interaction that causes a production incident is usually one where a new flow, introduced in the current release, fires alongside an existing automation and produces an unexpected result — a field that gets overwritten, a notification that fires twice, a record lock that prevents a subsequent update. UAT finds these because testers are running end-to-end scenarios, not isolated component tests.

Cross-browser and cross-device behaviour in Lightning

Lightning Experience renders differently across browsers, and the difference matters at scale. A custom LWC component that works perfectly in Chrome may render incorrectly in Safari — which is used by a significant portion of most enterprise sales teams. Automated testing against a single browser misses this entirely.

UAT covers the actual browser and device distribution of your user population — because testers are asked to use the environment your users actually work in.

Complementing automated testing with specialist UAT

The right answer isn't to choose between automated testing and UAT. Both have a place in a Salesforce delivery programme. The question is what each layer is responsible for.

Automated testing covers code correctness, regression safety, and scripted happy-path validation at speed and scale. UAT covers business fitness, user workflow coherence, edge case discovery, and the permission, data, and interaction scenarios that automated tests weren't written to find.

Organisations that invest in specialist Salesforce UAT — testers with genuine platform knowledge and enterprise context — consistently reach go-live with fewer unknowns. The issues that remain are manageable. The ones that would have made it to production don't.

That's the return on specialist UAT. Not a perfect system — no release is without risk. A system where the risks are understood and managed before they become incidents.