Salesforce UAT: Process, Checklist and Test Script Examples

Ask five Salesforce teams what UAT is and you get five answers, most of which amount to letting users click around before go-live and collecting what they say. That version produces a list of opinions, an argument about whether each one is a defect or a change request, and a sign-off nobody wants to put their name to.

Salesforce has published a definition, and it contains a second clause that the clicking-around version skips entirely.

Salesforce defines UAT as two checks and most teams run one

In its Trailhead module on the subject, Salesforce describes user acceptance testing as end-user testing performed in a sandbox or test environment to verify that a project or enhancement works as intended, and that what was originally requested is actually being delivered.

Read the two halves separately, because they are different activities.

First comes a functional check. Does the thing behave correctly when a user does what the system expects? That is what most UAT cycles test, and testers are good at it.

Second comes a scope check. Is this what the business asked for? That question is answered by comparison, not by exploration, and it requires something written down to compare against. Without it, a tester’s only reference point is their own expectation, which was never recorded and is therefore unarguable.

That consequence runs through everything below. A UAT cycle that only performs the first check cannot produce a defensible sign-off, because the business is being asked to accept delivery against a standard nobody stated. That is why sign-off meetings turn into negotiations.

Salesforce is also clear about who carries this. It features Dernie Hashemzadeh, who leads Salesforce’s own internal business analysis team, and places UAT under the business analyst’s purview, with the formality of an official sign-off described as a big part of the phase.

A test script performs the scope check that exploration cannot

So the instrument matters more than the schedule. A test script is the artifact that converts “does this seem right to you” into “does this match what was agreed”.

What makes a script work is not detail for its own sake. It is traceability in one direction and verifiability in the other: each script points back to a specific acceptance criterion, and each step has an expected result a tester can mark pass or fail without interpreting.

Three properties separate a script from a list of instructions.

It names the story or criterion it validates, so a failure is traceable to a commitment rather than to a preference. Mapping that across the whole project is the job of the matrix linking requirement to tested outcome.

It states a starting condition, because half of UAT failures are really setup failures. A script that begins “open the opportunity” without saying which opportunity, owned by whom, at what stage, will fail for reasons unrelated to the build.

It has an expected result written before the test runs. An expected result written afterwards is a description of what happened.

Where the acceptance criteria themselves come from, and why criteria that cannot fail are the root cause of unusable scripts, sits in how acceptance criteria get written.

Four script formats exist and two survive a sign-off dispute

Teams write UAT scripts in four familiar shapes. They are not equally defensible.

Narrative. “Check that the approval process works correctly for large deals.” One sentence, no steps, no expected result. Fast to write and worth nothing in a dispute, because two people can disagree about whether it passed.

Step-and-expect. Numbered actions, each with an expected result and a pass or fail box. The workhorse format and the right default for configuration.

Given-When-Then. Preconditions, action, expected outcome, inherited from the acceptance criteria. Strongest where the criterion was written that way already, since the script then needs no translation.

Scenario walkthrough. An end-to-end business process crossing several objects and users, testing the joins rather than the features. Essential and insufficient alone, because it finds integration problems and misses field-level ones.

Here is the same requirement in the two formats that hold up.

Both are verifiable by someone who was not in the requirements workshop. A narrative version of the same requirement, “test that big deals need approval”, is not.

Two things to notice in those examples. Each names a specific record, a specific role and specific values, which is what makes the result reproducible. And each states a timing expectation where one exists, because “appears in the queue” without a time bound is a criterion a tester cannot fail.

A UAT cycle runs in six stages, each ending in a decision

This process is short. What makes cycles overrun is running the stages out of order or skipping the decision at the end of one.

Smoke pass before tester briefing is the stage most often skipped and the one that protects the cycle. Twenty business users discovering a blocking error on script two costs a day of credibility you do not get back, and it converts a cycle into a reschedule.

Triage sits inside the cycle rather than after it, because a failure that is really a change request needs to leave the defect log before anyone counts it. How failures get classified once they are in the log is its own discipline, and the environment half of stage two belongs to the sandbox the cycle runs in.

The pre-access checklist has eleven items and four of them block

Before a single business tester receives a login, these should be true. Four marked blocking are the ones that waste everyone’s day if they are not.

Item three is the one teams underestimate. Testing as a system administrator proves nothing about what a sales rep can see, because visibility is the thing most likely to be wrong and the thing an admin profile hides. A UAT run entirely under administrator permissions will pass and then fail in week one of production.

Item six catches a Salesforce-specific trap with a precise mechanism. Salesforce documents that new and refreshed sandboxes default to System email only, a setting that permits automatically generated messages such as new user and password reset emails and nothing else. So a tester logs in without difficulty, and then never receives the approval notification their script asks them to confirm.

Three consequences follow from that one default. The notification works and gets logged as a defect. The setting resets every time the sandbox is refreshed, so clearing it once is not a permanent fix. And it is changed at Setup, under Deliverability, in the Access to Send Email section, where the options run No access, System email only and All email, with Salesforce able to restrict whether you can edit the level at all.

Items five and eleven are where the business has obligations rather than the project, and both belong in the plan as dated commitments, which is covered in the plan that gates this phase.

GetGenerative.ai turns the script library into a reusable asset

Script authoring is the stage that gets compressed, and it is the stage that decides whether the cycle produces evidence.

Arithmetic is unforgiving on a small team. A mid-sized project carries a few hundred acceptance criteria. Writing a step-and-expect script for each, with starting conditions and expected results, is days of careful work by the person who also runs the workshops and manages the stakeholders. So scripts get thinner, narrative creeps in, and the cycle loses its ability to settle a dispute.

GetGenerative.ai generates the case library from the same stories and acceptance criteria the project already produced, which removes most of that authoring cost and keeps the script traceable to its criterion by construction rather than by someone remembering to add a reference. Because the org itself gets read, a script can name fields and record types that exist rather than ones the design assumed.

What stays human is the judgment a generated script cannot supply. Which starting condition reflects how the business actually works. Which edge case matters enough to script. Whether an expected result is specific enough to fail. A generated library is a strong first pass that still needs someone to add the awkward cases, because the clean path is the one guaranteed not to find the defect. Teams who want this stage scoped properly can see how a delivery pod runs a cycle.

Testers need a role, a script and a way to record results

Most UAT advice treats testers as a resource to be scheduled. Failures here are more specific than availability.

A tester without a named script tests what interests them, which is useful exploratory feedback and not acceptance testing. Both have value; only one can support a sign-off.

A tester testing outside their real role produces results that do not transfer. A regional manager should test the manager scripts, not the rep scripts, because the manager’s visibility is what their scripts assert.

A tester with no agreed way to record a result records it in an email. Results scattered across inboxes cannot be counted, and a cycle whose pass rate is unknown cannot close.

And a tester who has not been told what happens to a failure assumes nothing happens, which is why the second half of a cycle goes quiet. Telling people that each failure gets triaged within a day, and that they will see the outcome, is what keeps results arriving on day four.

Which coverage these scripts should aim for across the whole project, as distinct from how a single cycle runs, belongs in the wider test strategy.

Agent behavior needs a script shape that outcome testing cannot provide

Where an agent is in scope, UAT acquires a problem the four formats above do not solve.

A step-and-expect script tests what came out. With an agent, a correct output produced by faulty reasoning passes that script and recurs later on a slightly different case. So an agent script needs a second expected result, about the path rather than the answer.

Salesforce now treats this as a business analyst competency rather than a developer one, which is a meaningful signal about where it sits in a project. Mechanics of validating agent behavior during UAT, including what a reasoning trace shows, are set out in what the BA credential now requires, and the broader test design around agents sits in the wider test design around agents.

Two practical adjustments for a cycle that includes agents. Write at least one script per agent topic whose expected result concerns the basis of the decision, not only the decision. And give agent scripts to testers who know the business rule well enough to notice a right answer reached the wrong way, which is usually a different person from the one testing the screen flows.

Sign-off commits the business to something specific or to nothing

Sign-off is where a vague cycle becomes an expensive cycle, because the signature either references something or it does not.

A signature against a named script set, with a recorded pass rate and a list of accepted known issues, commits the business to a defined state. Later discoveries are change requests, and that conversation is short.

A signature on a document saying UAT is complete commits the business to a feeling. Every later discovery is arguable, and the project absorbs work it did not scope.

Three elements make sign-off hold.

A named, versioned script set, so both sides know what was tested.

A result expressed as a count rather than an impression. Scripts attempted, passed, failed, and failures still open.

A known-issues list, with each item accepted explicitly by whoever is signing. An issue the business has read and accepted is not a surprise in week two.

Conditional sign-off is legitimate and should be written as a condition with a date, not as a verbal understanding that the two remaining defects will be fixed soon. Where that signature feeds next is the cutover it authorises, and the data that made the cycle realistic in the first place is its own topic, covered in making test data representative.

Six questions decide whether a UAT cycle is worth running

What is UAT in Salesforce?

Salesforce defines user acceptance testing as end-user testing performed in a sandbox or test environment to verify that a project works as intended and that what was originally requested is actually being delivered. The second clause is a scope check, which requires written acceptance criteria to compare against, and it is the half most cycles skip.

What does a Salesforce UAT test script look like?

Either step-and-expect or Given-When-Then. A usable script names the acceptance criterion it validates, states a specific starting condition including the record, role and values, and gives an expected result written before the test runs. Narrative scripts such as “check the approval process works” cannot settle a disagreement, because two people can disagree about whether they passed.

Who should run Salesforce UAT?

Business users testing in their own roles, coordinated by a business analyst. Salesforce places UAT under the business analyst’s purview and describes the formality of official sign-off as a major part of the phase. Testing under an administrator profile is the common error, since an admin profile hides exactly the visibility problems UAT should catch.

What should be checked before UAT starts?

Four items block: every in-scope criterion has a script, every script has a starting condition and expected result, test users exist with real profiles and roles, and a smoke pass has cleared the core paths. Seven more matter, including test records, email deliverability, integrations pointed at test endpoints, an agreed logging method, severity definitions, named testers, and agreed cycle dates. Email deliverability is the one teams miss, because new and refreshed sandboxes default to System email only, which blocks the notifications a script asks a tester to observe.

Why do Salesforce UAT cycles overrun?

Usually because the smoke pass was skipped, so business testers hit a blocking error early and the cycle becomes a reschedule. Another recurring cause is triage happening after the cycle rather than inside it, which leaves change requests sitting in the defect log and makes the failure count meaningless.

How is UAT different for Agentforce agents?

An outcome-only script passes a correct answer reached by faulty reasoning, which then recurs on a different case. Agent scripts need a second expected result concerning the basis of the decision rather than the decision itself, and they should be given to testers who know the underlying business rule well enough to spot sound reasoning from unsound.