User Acceptance Testing in Salesforce is where most release problems surface. When UAT gets rushed, they surface in production instead. This guide walks the full cycle: which sandbox to use, how to structure test scripts, the meeting cadence that keeps stakeholders engaged, and the sign-off discipline that protects you from "we never agreed to that."
Why Salesforce UAT matters more than other UAT
Three reasons it's uniquely critical in Salesforce orgs.
Configuration is code. A formula field, a validation rule, a flow: any of them can break a workflow that ten teams depend on. UAT is where a user says "but we use this every Monday" before it ships.
The platform is interconnected. Changes ripple. A new required field on Account affects every Lead conversion, every report, every integration. UAT catches the dependencies QA misses.
Your training material is part of the release. UAT exercises your help docs, in-app guidance, and training materials too. If users can't follow the script, the documentation isn't ready either.
Step 1: pick the right UAT sandbox
| Sandbox type | When to use for UAT |
|---|---|
| Partial Copy | Default for most releases. 5-day refresh, sample data via template, $$ |
| Full Copy | Major releases, regulated industries, integrations needing 1:1 prod data, $$$$ |
| Developer Pro | Never. No representative data. Use only for solo dev work. |
The naming convention I recommend: dedicate one sandbox suffix exclusively to UAT (for example yourorg--UAT), refresh it at the start of each release cycle, and freeze it during the UAT window so testers see a consistent state. See Salesforce sandbox types for the full comparison.
Step 2: refresh and seed the sandbox
Before testers log in:
- Refresh the UAT sandbox, or stand up a fresh one. How to refresh a Salesforce sandbox walks through the steps.
- Apply data masking if your org handles PII. The Salesforce Data Mask product has templates for common patterns; OwnBackup, Plauti, or custom Apex work too.
- Repoint named credentials and connected app callback URLs at sandbox-friendly endpoints: the test instance of the payment processor, sandbox MuleSoft, and so on.
- Enable test users, not the testers' production accounts, with the same profiles and permission sets they'll have in prod.
- Reset passwords and disable any 2FA factors that won't work in the sandbox domain.
Step 3: write the test scripts
Each user story gets a script. The minimal columns:
| # | Step | Expected Result | Actual Result | Pass/Fail | Notes |
Keep scripts short, 10 to 15 steps. Longer ones get skimmed or skipped. Group related scripts under each user story, and store them in Google Sheets, Excel, or a test management tool like TestRail or Xray (Atlassian).
A good UAT step looks like this:
Step 4. Click the "Convert" button on Lead
LD-2024-001. Expected: A new Opportunity is created with Amount = $50,000 and Close Date = today + 30 days. Lead status changes to "Converted."
Avoid steps like "verify the system works correctly." Testers won't catch what's hiding inside that. Each step should be one observable action and one observable outcome.
Step 4: run the UAT sessions
Two formats work. Async self-paced testing lets people run scripts on their own schedule and log results in a shared sheet, which suits distributed teams. Live group sessions put everyone through the scripts together over Zoom or Teams, which suits high-stakes releases and testers who are new to UAT.
Either way, schedule daily standups during the UAT window: 15 minutes, async in Slack or live. Track the burndown of pass, fail, and blocked. The standup is where blockers surface. "I can't reach the integration sandbox." "The test data Smith Industries account is missing."
Step 5: triage defects
For each fail, decide quickly:
- Critical, blocking a core workflow. Stop UAT, fix it, redeploy to UAT.
- Major, works but inconvenient. Fix it before the prod deploy.
- Minor, cosmetic or an edge case. Log it for next sprint and don't block the release.
- Out of scope, pre-existing or a different feature. File it separately.
The riskiest pattern is treating every fail as critical and redeploying to UAT every day. Each redeploy resets the test cycle and erodes tester trust. Batch the fixes into daily or every-other-day deploys, and rerun only the affected scripts.
Step 6: get sign-off
Before any production deploy, get written sign-off from each business owner of the changes. The sign-off should say explicitly:
"I have reviewed the test results in [link to spreadsheet]. The functionality meets [the requirements / user stories X, Y, Z]. I approve deployment to production."
Send it by email, ticket comment, or a Confluence page. Keep it short and precise. Vague approvals like "looks good" protect nobody when something breaks in prod.
UAT sign-off checklist
- All test scripts run, pass/fail recorded
- Critical and major defects are either fixed and re-tested or accepted with mitigation
- Business owner signed off in writing
- Release notes drafted
- Training materials updated
- Communications scheduled (in-app banner, email, Slack)
- Rollback plan documented (which package version + restore-from-backup steps)
- Production deploy window booked
- Post-deploy smoke-test plan ready
Common mistakes
- Letting UAT slip onto the developer. Business users have to run it. Devs and QA already caught the bugs they were going to catch.
- A stale UAT sandbox. A six-month-old sandbox doesn't represent production anymore. Refresh at the start of every release cycle.
- Skipping the refresh after a major data load. Test data drifts, and UAT starts finding bugs that don't exist in prod.
- No sign-off paper trail. "We agreed verbally" is worth nothing when the CFO calls about a broken month-end report.
- Testing only happy paths. Include two or three negative scenarios per script: empty fields, the wrong record type, a user who lacks permission.
UAT done well is the cheapest insurance you'll buy in a Salesforce release. A bug found in UAT means the process worked. The outcome to avoid is shipping something the business didn't actually need, and the discipline above is what prevents it.
Leave a Comment