A good Salesforce UAT plan has business users, not admins, prove that the system supports their real work before launch. It starts only when the build is finished and realistic data sits in a full or partial copy sandbox. Testers sign in as their actual roles and follow scripts written from user stories. Defects get logged with clear severity and are retested before anyone signs off. The plan ends with written exit criteria that feed the go/no-go decision.
What is UAT for, and how is it different from the partner's testing?
UAT answers one question: can the people who will use Salesforce do their jobs in it? Earlier testing answers a narrower question, which is whether the build works as specified.
Your partner should already have run unit, system and integration tests before handing over the org. Those confirm that a Flow fires, a field calculates and a sync moves records. They rarely catch a process that matches the spec but not reality. A sales manager may find the approval step sits with the wrong person. A service agent may need three clicks where the old tool needed one. That is the gap UAT exists to close.
Treat UAT as a business activity with technical support, not the reverse. The client-side project lead owns the plan and the sign-off. The partner supplies environments, fixes and triage help.
When is a Salesforce build ready to enter UAT?
UAT should start only when the build is complete for the scope being tested and test data is loaded. Starting early turns acceptance testing into unpaid development review.
Write entry criteria down and check each one before inviting testers:
- All in-scope user stories are built and have passed the partner's system testing.
- Integrations in scope are connected to test endpoints, not stubbed out.
- Test users exist for every role, with real profiles, permission sets and role hierarchy positions.
- Representative data is loaded, including migrated records if a migration is part of the project.
- Known open defects from earlier testing are listed, so testers do not log them twice.
- Testers have the scripts, a defect form and a named contact for questions.
The environment matters. Per Salesforce, a Partial Copy sandbox holds your metadata and a subset of records chosen through a sandbox template. Full sandboxes replicate all production data and metadata. Developer and Developer Pro sandboxes copy configuration only, which makes them a poor fit for UAT. Refresh limits apply, and Salesforce lists five days for Partial Copy and 29 days for Full. Sandbox allowances depend on your edition and contract, so confirm what you own with your Salesforce account team. Our release management guide covers how each sandbox fits a wider deployment path.
Who should do the testing, and how do they sign in as their role?
Testers should be the people who will use the system daily, picked by role. An admin testing as an admin will miss most of what a field rep or billing clerk would hit.
Pick at least one tester for each distinct role: a rep, a manager, a service agent, an operations user, a finance user. Protect their calendars, since UAT squeezed between normal duties tends to stall.
Each tester should sign in to the sandbox as a test user that carries the same profile, permission sets and role as the real job. That is the only way to test sharing, field visibility and page layouts honestly.
Salesforce's Login As feature lets an administrator open a session as another user, and it is handy for quick checks. It has limits worth knowing. The admin cannot log in as an inactive user. The session skips that user's own sign-in, so single sign-on and multi-factor prompts go untested. Login activity also shows in Setup Audit Trail under the admin's name as delegate. Use it for triage, and let real testers use real test logins.
How do you write test scripts testers can actually follow?
Write each script from a user story and its acceptance criteria. If a story has no testable criteria, fix the story before writing the script.
A useful script names the role, the starting record, each step in plain words and the expected result after each step. Keep the language in the tester's terms, such as "convert the lead from the trade show" rather than "execute lead conversion." Include unhappy paths: a missing required field, a discount above the approval threshold, a duplicate account. Our guide to Salesforce requirements and user stories explains how to write acceptance criteria that convert cleanly into scripts.
Number every script and map it back to its story. That trace shows at sign-off which requirements were tested, which passed and which were waived.
Why do end-to-end scenarios matter more than single screens?
Most serious UAT findings appear where one team hands work to another or where data crosses an integration. Testing screens in isolation misses those handoffs.
Build a handful of scenarios that follow real work across objects and teams. A lead arrives from a web form, gets routed, converts, becomes an opportunity, wins approval and creates an order in the ERP. A case arrives by email, escalates, triggers a field visit and closes with a survey. Have each role perform its own step, in sequence, under its own login. Then check the downstream system received what it should have.
What data should testers use?
Use data that looks like production: real volumes of picklist values, messy addresses, long account names, old closed records. Clean demo data hides the problems production data will reveal.
A Full sandbox brings real records with it, which raises privacy questions when testers should not see customer details. Masking or anonymizing sensitive fields before testers arrive is good practice. Salesforce offers Data Mask for this, and its help pages say the legacy managed package is being replaced by Data Mask & Seed. Confirm current availability and licensing with your account team. Whatever tool you use, keep a short list of seeded test records with known values, since reports will be checked against them.
How should testers log defects, and how severe is each one?
Every defect needs reproducible steps, the tester's role, the record used, what was expected and what happened. A screenshot helps, but steps matter more.
Agree severity definitions before testing starts, so labels reflect impact rather than frustration. A simple four-level scale works for most projects:
| Severity | Definition | Example | Go-live impact |
|---|---|---|---|
| Critical | Blocks a core process with no workaround, or exposes data to the wrong people | Reps can see accounts outside their territory; orders fail to reach the ERP | Blocks go-live until fixed and retested |
| High | Core process works only with a painful or risky workaround | Quote approval routes to a manager who left the team | Fix before launch, or launch only with a documented workaround the business accepts |
| Medium | Secondary process affected; reasonable workaround exists | A report filter excludes one record type | Can launch; schedule the fix for hypercare |
| Low | Cosmetic or minor usability issue | Field label misspelled; awkward field order on a layout | Can launch; add to the backlog |
Hold a short triage meeting at a fixed cadence while UAT runs, often daily. The project lead, a partner consultant and a business owner confirm severity, assign each defect and decide whether it is a defect at all. Tracking can live in a ticketing tool or in a simple custom object inside Salesforce, as long as everyone uses one list.
How do you handle retests and regression?
Each fix goes back to the tester who found it, who reruns the original steps under the same role. A developer marking something resolved is not the same as the business accepting it.
Fixes have side effects. A changed validation rule can break an import, and a sharing tweak can hide records elsewhere. After each batch of fixes, rerun a small regression set covering the core end-to-end scenarios. Where scripts repeat across releases, automated UI or API tests can carry part of the load. They supplement business testers rather than replacing them.
How do you test reports, dashboards and AI features?
Test reports against numbers you already know. Seed a set of records with known amounts and dates, calculate the expected totals by hand, then compare every key report and dashboard.
Have each manager open their own dashboard under their own login, since running-user settings and sharing change what appears. A dashboard showing the wrong total is a high-severity defect if leaders will steer the business by it.
Agentforce agents and other AI features need a different method, because the same input can produce different responses. Business testers still judge whether answers are useful and safe. The scoring, test sets and tooling are covered in our guide to testing Agentforce agents.
What about testing on phones and tablets?
If people will use the Salesforce mobile app, test on the devices they actually carry. Desktop testing says little about how a page behaves on a small screen.
Check that compact layouts show the right fields, that quick actions appear and work, and that any offline expectations hold. Field users should also try weak-signal conditions where that applies. Log mobile defects separately so the device and operating system are always recorded.
Is that finding a defect or a new request?
A defect is something that fails an agreed acceptance criterion. Anything else, however sensible, is an enhancement and goes to the backlog for a decision.
UAT always surfaces good ideas, because users are finally seeing the real system. Treating each one as a defect is how launch dates slip. Give enhancements their own category in the defect log and have a business owner rule on them weekly. A few justify a scope change; most can wait.
What does sign-off look like, and how does it feed go/no-go?
Sign-off is a written statement from the business owner that exit criteria are met, with any exceptions listed. It is an input to go/no-go, not the decision itself.
Typical exit criteria include every critical script passed, no open critical defects, and open high defects either fixed or covered by accepted workarounds. Lower-severity items should be logged with owners. Record the version tested, who signed, and the open items they accepted. The go/no-go meeting then weighs UAT results alongside data, training and cutover readiness, as our go-live checklist describes.
What should phase one of a UAT plan include?
Start small and concrete. A first UAT plan for a typical Sales Cloud or Service Cloud rollout can be built from a handful of decisions:
- Name the UAT owner on the client side and the partner contact for triage.
- Confirm the sandbox type, its data load and its masking approach.
- List roles and pick one or two testers per role, with protected time.
- Write scripts for the core end-to-end scenarios first, then single-story scripts.
- Agree severity definitions and the triage cadence before day one.
- Write entry and exit criteria, and the sign-off template, in advance.
Planning a rollout? Our implementation team can review your UAT plan alongside the build.
