User Acceptance Testing (UAT)
User Acceptance Testing (UAT) in Salesforce project delivery is the testing phase where end users validate that the implementation meets business requirements and behaves correctly in real-world scenarios before final sign-off and production go-live.
Definition
User Acceptance Testing (UAT) in Salesforce project delivery is the testing phase where end users validate that the implementation meets business requirements and behaves correctly in real-world scenarios before final sign-off and production go-live. UAT happens after system testing and integration testing have confirmed the technical correctness of the build; UAT verifies that the build actually solves the business problem from the perspective of the people who will use it daily. The phase is mandatory for any non-trivial Salesforce project because business users find issues that developers and testers cannot anticipate.
UAT in Salesforce is typically conducted in a Full Copy sandbox or a dedicated UAT environment that mirrors production as closely as possible: same metadata, same integrations enabled, representative sample data, real user profiles and permissions. End users execute scripted test scenarios covering their key workflows and capture findings: passes, failures, change requests, suggestions. Sign-off from UAT is the gating event for go-live; without explicit business signoff, the project does not move to production. The discipline distinguishes successful Salesforce deployments from troubled ones.
The UAT process and what makes it successful
Environment setup for UAT
UAT requires an environment that closely resembles production: a Full Copy sandbox refreshed from production with metadata deployed to match the planned go-live state, integrations configured to point at appropriate test endpoints, sample data sufficient to exercise the key workflows. The environment setup is often the first multi-week task in the UAT phase. Skipping or shortening this step produces UAT findings that may be specific to the test environment rather than reflective of real production behavior. Mature delivery programs treat the UAT environment as a critical asset: dedicated, documented, refreshed on a known cadence, supported with the same operational rigor as production.
Test script design
Effective UAT depends on well-designed test scripts. Each script covers a specific business scenario: a sales rep creating a new lead and converting it to opportunity, a service agent receiving a case and resolving it through the standard workflow, a finance user generating a quarterly revenue report. The scripts include the steps to execute, the expected outcomes at each step, and any acceptance criteria the user should verify. Generic scripts produce generic findings; scripts written from the specific user persona perspective with realistic data produce meaningful findings. Test script design is a deliverable in its own right and benefits from review by the business stakeholders before UAT begins.
User selection and training
The right UAT participants are domain experts who will use the system daily, not project team members or technical staff. A typical UAT cohort includes representatives from each user persona: senior salespeople, frontline service agents, regional managers, finance users. Each participant should be trained on the new system briefly before UAT begins so they can navigate the basic workflows without confusion. Without training, participants spend UAT time figuring out the UI rather than evaluating the business logic. Without domain expertise, participants miss the subtle issues that experienced users would catch immediately. Both training and expertise matter.
Issue tracking and triage
UAT generates a stream of findings: bugs, change requests, unclear requirements, performance issues, training needs. Each finding goes into the project's issue tracking system (Jira, Asana, ServiceNow) with categorization, severity, and assignment. The triage process prioritizes findings: blockers (must fix before go-live), high-priority (should fix before go-live), low-priority (defer to post-launch enhancement). The triage discipline is what keeps UAT productive; without it, every finding becomes equally urgent and the team cannot focus on what actually matters for go-live. Mature programs run daily triage meetings during active UAT to maintain velocity.
Sign-off and go-live readiness
UAT concludes with formal sign-off from the business stakeholders: documented agreement that the system meets requirements and is ready for production. The sign-off is more than a formality; it represents shared accountability between the project team and the business for the production launch. Sign-off conversations sometimes surface late requirements or concerns that need addressing before go-live, which is exactly the right moment for the conversation. Programs that skip formal sign-off and rush to go-live frequently discover business-blocking issues in production, where the cost of fixing is much higher.
Common UAT pitfalls
Several pitfalls recur in Salesforce UAT engagements. Insufficient training of UAT participants means findings reflect confusion rather than real issues. Inadequate test data means key scenarios cannot be exercised. Ambiguous test scripts mean every participant tests differently and findings are inconsistent. Late UAT scheduling means business users do not have enough time to thoroughly test before go-live pressure forces sign-off. Missing integration testing in UAT means production integrations break in ways UAT could have caught. Each pitfall is preventable with disciplined UAT planning, but they all recur in projects that have not invested in the UAT preparation work. The UAT phase is often where Salesforce projects either prove their quality or expose their gaps; investing in UAT well pays back through smoother production launches.
UAT versus other testing phases
UAT is one phase in a broader testing hierarchy. Unit testing validates individual components in isolation (Apex test methods, LWC unit tests). Integration testing validates that components work together correctly. System testing validates the full system against technical specifications. UAT validates the system against business requirements with real users. Each phase has its place and serves different validation goals. Production-like performance testing and regression testing typically run alongside or just before UAT. The complete testing program for a Salesforce project includes all of these phases; UAT is the user-facing validation that sits closest to the go-live decision.
UAT in agile delivery models
Traditional waterfall Salesforce projects schedule UAT as a defined phase at the end of the build. Agile delivery models distribute UAT across sprints: at the end of each sprint, the sprint review includes business stakeholders validating the sprint's deliverables, with formal UAT at the end of each release cycle aggregating the sprint-level validations. The agile model produces faster feedback loops and catches issues earlier, but requires more business stakeholder engagement across the project timeline. Programs that have moved from waterfall to agile typically report that the per-sprint UAT model improves quality and reduces end-of-project surprise, though the cumulative business stakeholder time can be higher. The right model depends on the org's project methodology and the business team's availability for sustained engagement. Hybrid models that combine sprint-level validation with phase-end formal UAT are common and often work well, capturing the feedback benefits of both approaches. Regardless of the model chosen, the principle remains: business users must validate the build against business requirements before production launch, with appropriate documentation and sign-off discipline to make the validation meaningful and accountable rather than a checkbox exercise.
Run a successful Salesforce UAT
Running effective UAT requires planning, environment setup, participant management, and disciplined execution. The workflow below covers the standard sequence for a Salesforce project's UAT phase from preparation through sign-off.
- Prepare the UAT environment
Refresh a Full Copy sandbox from production with the planned go-live metadata deployed. Configure integrations to point at appropriate test endpoints. Load representative sample data covering all key scenarios. Provision UAT participant users with realistic profiles and permission sets. Verify the environment behaves as production would, with all standard automation, reports, and dashboards functional. Document the environment state so participants know what they are testing against.
- Author test scripts and brief participants
Develop UAT test scripts covering each major business scenario. Each script should have clear steps, expected outcomes, and acceptance criteria. Review the scripts with business stakeholders for completeness and accuracy. Select UAT participants representing each user persona. Run a brief training session covering the new UI, key workflows, and how to log findings. Schedule the UAT window with clear start and end dates plus daily check-in meetings during the window.
- Execute UAT with daily triage
Run the UAT window with participants executing test scripts and logging findings in the project's issue tracking system. Hold daily triage meetings to review new findings, categorize them by severity, and assign owners for remediation. Address blocker and high-priority issues quickly so participants can continue testing. Communicate progress to project sponsors through a daily status update. Iterate the test scripts if specific scenarios surface as problematic.
- Resolve issues and obtain sign-off
After the UAT window closes, work through the remaining issues with the dev team. Categorize each finding as fix-before-go-live or defer-to-post-launch. Re-test the fixed issues with the relevant UAT participants. Once all blockers are resolved, schedule the sign-off meeting with business stakeholders. Walk through the UAT results, any outstanding issues, and the readiness assessment. Obtain documented sign-off before scheduling production go-live.
- Skipping UAT or shortening it under schedule pressure produces production incidents that cost more than the UAT investment would have.
- Wrong participants (project team members instead of end users) produce UAT findings that do not reflect real business usage.
- Insufficient training means findings reflect confusion rather than real issues; brief UAT training is non-negotiable.
- Ambiguous test scripts produce inconsistent findings across participants and weak overall coverage.
- Skipping integration testing in UAT means production integration issues surface after launch, in front of users.
Trust & references
Straight from the source - Salesforce's reference material on User Acceptance Testing (UAT).
- Sandbox EnvironmentsSalesforce Help
- Salesforce ArchitectsSalesforce
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is UAT?
Q2. Who performs UAT?
Q3. What does UAT catch?
Discussion
Loading discussion…