Why most Salesforce projects get their UAT phase wrong

I have worked on dozens of Salesforce projects. And I have seen the same pattern repeat every time a go-live turns into a disaster: the UAT phase was badly designed, rushed, or both.

This is not a technical problem. It is a problem of organisation and planning. And it is always created long before UAT begins.

The 5 mistakes that wreck Salesforce UAT

1. UAT is scheduled too late and made too short

The classic pattern: development runs late, the overall schedule does not move, and the UAT phase is squeezed to hold the go-live date. Three planned weeks become five actual days.

The result: testers do not have the time to cover every scenario. Non-critical defects are parked “in the backlog” and end up in production. Quality debt starts building on day one.

2. The wrong people run the tests

This is the most common mistake. UAT is handed to the developers, to the IT team, or to a project manager who knows the system better than any user does. Those people test what they designed, with clean data and predictable scenarios.

What you need instead: end users. The sales reps who will log an opportunity straight after a phone call. The customer service team handling a complex case with real data. They are the ones who find the real problems.

3. There are no defined acceptance criteria

Is a defect a blocker or not? Asked during UAT with no pre-agreed answer, that question creates endless arguments between the project team and the customer. Everyone has their own definition of “acceptable”.

The fix: define the acceptance criteria before development starts, not during UAT. What blocks the go-live? What can wait for the first patch? That framing has to exist in writing.

4. The test data looks nothing like production

UAT runs on 10 clean accounts, with well-filled fields and linear scenarios. Production is 50,000 accounts with missing data, special characters in names, and edge cases nobody had anticipated.

Testing with data that looks nothing like reality buys peace of mind without reducing the real risk.

5. There is no UAT lead

UAT is organised, the testers are named, defects are logged in a spreadsheet. But nobody owns tracking progress, prioritising fixes, or deciding what is a blocker and what is not.

Without a clearly named lead, UAT drifts. Defects pile up without being dealt with. Decisions are not made. And the go-live gets closer.

How to run a Salesforce UAT that works

The sign that UAT is going to go well

Projects whose UAT goes well all have one thing in common: end users were involved early. Not just at UAT, but from the design workshops onwards. They helped define the scenarios, they signed off the mockups, and when UAT starts they know what they are going to test and why.

UAT is not a stage at the end of a project. It is the outcome of a validation process that starts at the very first workshop.