Salesforce UAT: Sandbox Setup, Testing Process & Sign-Off Checklist

User Acceptance Testing in Salesforce is where most release problems surface — or get missed and cause a production fire instead. This guide walks through the full UAT 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 UAT is uniquely critical in Salesforce orgs:

1. 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 users surface "but we use this every Monday" before it ships.
2. The platform is interconnected. Changes ripple — a new required field on Account affects every Lead conversion, every report, every integration. UAT catches the dependencies that QA misses.
3. Custom training material is yours to maintain. UAT also exercises your help docs, in-app guidance, and training materials. If users can't follow the script, your 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 sandbox naming convention I recommend: dedicate one sandbox suffix exclusively to UAT (e.g., yourorg--UAT), refresh it at the start of each release cycle, and freeze it during the UAT window so testers see consistent state. See Salesforce sandbox types for the full comparison.

Step 2 — Refresh and seed the sandbox

Before testers log in:

1. Refresh the UAT sandbox (or use a fresh one). How to refresh a Salesforce sandbox walks through the steps.
2. Apply data masking if your org handles PII. The default Salesforce Data Mask product has templates for common patterns; alternatives like OwnBackup, Plauti, or custom Apex work too.
3. Reconfigure named credentials and connected app callback URLs to point at sandbox-friendly endpoints (test instance of payment processor, sandbox MuleSoft, etc.).
4. Enable test users — not the testers' production accounts — with the same profiles + permission sets they'll have in prod.
5. 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 scripts get skimmed or skipped. Group related scripts under each user story. Store in Google Sheets, Excel, or a test management tool like TestRail / 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 issues hidden 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. Testers run scripts on their own schedule, log results in a shared sheet. Best for distributed teams.
• Live group sessions. Everyone meets, runs scripts together over Zoom/Teams. Best for high-stakes releases or when testers are new to UAT.

Either way, schedule daily standups during the UAT window (15 min, async via Slack or live). Track the burndown of pass/fail/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 — blocks core workflow → stop UAT, fix and redeploy to UAT.
• Major — works but inconvenient → fix before prod deploy.
• Minor — cosmetic or edge case → log for next sprint, don't block release.
• Out of scope — pre-existing or different feature → file 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 fixes — daily or every-other-day deploys to UAT — and rerun affected scripts only.

Step 6 — Get sign-off

Before any production deploy: written sign-off from each business owner of the changes. The sign-off should explicitly state:

"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 via email, ticket comment, or a Confluence page. Keep it short and precise — vague approvals like "looks good" don't protect anyone if 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. UAT must be run by business users — devs/QA caught the bugs they were going to catch in QA.
• Stale UAT sandbox. A 6-month-old sandbox doesn't represent production anymore. Refresh at every release cycle start.
• Skipping the sandbox refresh after a major data load. Test data drifts; UAT finds 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. Always include 2-3 negative scenarios per script: what happens with empty fields, with the wrong record type, with a user who lacks permission?

UAT done well is the cheapest insurance you'll buy in a Salesforce release. The worst outcome is not "UAT found a bug" — it's "we shipped something the business didn't actually need." That's what the discipline above prevents.