Salesforce UAT should answer one practical question: can the people who use Salesforce every day complete their real work successfully after this release?
By the time a release reaches UAT, most technical testing should already be complete. UAT is where business users work through realistic scenarios using the roles, data, approvals, and processes they will rely on after deployment.
The checklist below reflects the areas we would normally review before recommending a Salesforce release for production.
What Should a Salesforce UAT Checklist Include?
Start with the areas that could disrupt users or business operations if they fail. Do not try to test every Salesforce feature. Concentrate on what actually changed and the processes connected to those changes.
1. Map Requirements to Real Test Scenarios
Take each important requirement or user story and turn it into something a user would actually do.
For example, instead of testing:
"Opportunity automation works correctly."
Test a complete scenario:
"A sales representative moves an opportunity to Proposal, adds the required information, submits the discount for approval, and receives the expected next action."
For every scenario, document:
- User performing the task
- Starting conditions
- Steps to complete
- Expected result
- Business priority
- Pass or fail status
This makes UAT easier to execute and prevents vague sign-off decisions.
2. Test With the Right Roles and Permissions
One of the most common UAT mistakes is testing everything with an administrator account.
That tells you very little about what real users will experience.
Run important scenarios using representative users such as:
- Sales representatives
- Sales managers
- Service agents
- Operations users
- Finance users
- Approval managers
Check whether they can see the correct records, edit the required fields, access relevant objects, and complete the actions expected from their role.
Also test what users should not be able to access. Permission issues are not limited to missing access. A release can also accidentally expose records, fields, or actions to the wrong users.
3. Walk Through Complete Business Processes
Avoid testing individual screens in isolation.
If lead conversion is part of the release, follow the process from the lead record through conversion and into the resulting account, contact, and opportunity.
Depending on the Salesforce implementation, critical UAT flows may include:
- Lead conversion
- Opportunity progression
- Quote creation
- Discount approvals
- Case escalation
- Customer onboarding
- Record ownership changes
- Contract updates
- Customer information changes
Prioritise workflows that are used frequently, generate revenue, affect customers, or create significant operational problems when they fail.
4. Use Realistic Data
Perfect test records can hide problems that production users will encounter immediately.
Use data that reflects real Salesforce records, including different account types, missing optional information, existing relationships, duplicate possibilities, and different ownership structures.
During testing, check:
- Required fields
- Validation rules
- Calculated fields
- Lookup relationships
- Record visibility
- Duplicate handling
- Status changes
- Related record updates
Pay particular attention to data created or updated automatically during the workflow.
For example, if closing an opportunity updates an account field, creates a task, and triggers an approval, check all of those outcomes rather than stopping once the opportunity status changes.
5. Test Automation Within the Business Flow
Salesforce automation rarely operates on its own.
A Flow may update a field, trigger an approval, send a notification, create a task, or pass information to another system. During UAT, test that automation as part of the complete user journey.
For example:
- A user updates an opportunity.
- A validation rule checks required information.
- Salesforce Flow updates related fields.
- An approval request is created.
- The manager approves it.
- Salesforce updates the opportunity status.
- The user receives the expected notification.
The purpose of UAT is not to repeat detailed technical testing of every Flow or integration. Instead, Salesforce UAT testing should focus on whether users can complete the intended business process correctly from beginning to end.
Instead, check whether the automation allows the user to complete the business process correctly from beginning to end.
6. Check Integrations in Real Workflows
If Salesforce exchanges information with ERP systems, payment platforms, marketing tools, support applications, or other external systems, include those touchpoints in relevant UAT scenarios.
Focus on what the business user depends on.
For example:
- Does customer information appear where expected?
- Does an approved record move to the connected system?
- Does Salesforce show the correct status after the external action?
- Are users given a useful message when something fails?
- Can they continue their work without manual intervention?
Detailed API behaviour should normally be covered earlier through integration testing. During UAT, the concern is whether the connected process works from the business user's perspective.
7. Check Reports and Dashboards
Reports are often overlooked during UAT because the underlying record update appears to work correctly.
However, users may rely on those records for pipeline reviews, service reporting, forecasting, compliance, or management dashboards.
After completing important workflows, check whether the resulting data appears correctly in relevant reports.
Review:
- Report filters
- Record inclusion
- Calculated values
- Groupings
- Dashboard totals
- User visibility
- Newly introduced fields
A process should not be considered complete if the operational record works but the reporting used by the business becomes inaccurate.
8. Review Everyday User Experience
A Salesforce change can technically work and still make routine work harder.
Ask testers to pay attention to practical usability while completing UAT.
Check whether:
- Important fields are easy to find
- Page layouts make sense
- Users understand what action to take next
- Error messages provide useful information
- Required steps are reasonable
- New screens behave consistently with existing processes
- Users can complete common tasks without unnecessary workarounds
Small usability issues become much more noticeable after deployment when people repeat the same process several times each day.
9. Test What Happens When Things Go Wrong
Do not run only the successful path.
Real Salesforce users forget fields, enter unexpected values, reject approvals, change records midway through a process, and attempt actions they do not have permission to perform.
Include scenarios such as:
- Missing required information
- Invalid field values
- Rejected approvals
- Restricted record access
- Duplicate records
- Reassigned ownership
- Cancelled processes
- Changed information after submission
- Incomplete integration data
- Unexpected status changes
The objective is not to test every possible failure.
Focus on exceptions users are reasonably likely to encounter and situations that could create a significant business problem.
Defect Tracking During Salesforce UAT
When a UAT scenario fails, avoid logging defects such as:
"Approval not working."
That does not give the delivery team enough information to reproduce the issue.
A useful UAT defect should include:
- User or role involved
- Salesforce record used
- Steps performed
- Expected result
- Actual result
- Screenshot or evidence where useful
- Business impact
- Severity
- Related test scenario
Business impact is particularly important during UAT.
A field alignment issue and a defect preventing sales users from submitting a quote should not be treated with the same urgency.
Retest Fixes Before Sign-Off
Once a UAT defect has been fixed, rerun the scenario that originally failed.
Do not assume that a development fix automatically resolves the business problem.
For changes affecting shared components such as Flows, validation rules, common objects, or integrations, retest related scenarios as well.
For example, changing an Opportunity Flow to fix one approval problem could also affect another opportunity stage or user group.
Retesting should therefore cover both the original defect and any important connected workflows.
UAT Sign-Off and Go/No-Go Decision
UAT completion should not simply mean that everyone finished their assigned test cases.
Before sign-off, review:
- Number of scenarios passed
- Remaining defects
- Severity of unresolved issues
- Business impact of those issues
- Available workarounds
- Retesting results
- Known deployment risks
A minor formatting issue may be acceptable for release.
A defect preventing sales users from generating quotes, service users from accessing cases, or managers from approving critical records probably requires a different decision.
The final go/no-go decision should reflect business risk, not just the percentage of test cases marked as passed.
Final Salesforce UAT Pre-Deployment Checklist
Before moving the Salesforce release into production, confirm that:
- [ ] Critical UAT scenarios have passed
- [ ] High-risk business workflows have been tested
- [ ] Representative user roles have completed testing
- [ ] Required permissions and record access are correct
- [ ] Users cannot access restricted records or actions
- [ ] Validation rules behave as expected
- [ ] Salesforce automation works within complete workflows
- [ ] Business-critical integrations work within tested scenarios
- [ ] Important reports and dashboards show expected results
- [ ] Negative and exception scenarios have been covered
- [ ] Failed scenarios have been retested after fixes
- [ ] Blocking defects have been resolved
- [ ] Remaining defects have documented business impact
- [ ] Accepted risks have been reviewed with stakeholders
- [ ] Business owners have provided sign-off
- [ ] The team has made a clear go/no-go decision
Conclusion
A useful Salesforce UAT checklist should reflect the way people actually use Salesforce, not become a long list of isolated features to click through.
Test with realistic users, permissions, records, workflows, approvals, integrations, and exceptions. Follow critical processes from beginning to end and make unresolved business risks visible before sign-off.
That gives stakeholders stronger evidence for deciding whether a Salesforce release is genuinely ready for production.
Top comments (0)