How to Write Effective UAT Test Cases for Salesforce

You’ve spent weeks working on a Salesforce project. The requirements are documented, the configuration is complete, and everything appears to be working.

Now it’s time for user acceptance testing (UAT).

But there’s a problem. Your test cases are vague, your testers aren’t sure what they’re supposed to do, and you’re getting feedback like “It doesn’t work” without enough information to understand what went wrong.

Sound familiar?

Good UAT doesn’t have to be complicated. But it does require more than asking a few people to click around Salesforce and tell you whether everything looks okay.

The goal is to give your business users clear, realistic scenarios that help them confirm whether your solution actually meets their needs.

In this guide, we’ll walk through how to create effective Salesforce UAT test cases, what to include, common mistakes to avoid, and practical examples you can use in your own projects.

Jump to a section:

• What Is a Salesforce UAT Test Case?
• What Makes a Good UAT Test Case?
• A Practical Salesforce UAT Test Case Example
• How to Create Your Own UAT Test Cases
• Common UAT Mistakes and How to Avoid Them
• Preparing for and Executing UAT
• Salesforce UAT Test Case Checklist
• Final Thoughts: Better UAT Starts With Better Test Cases

What Is a Salesforce UAT Test Case?

A UAT test case is a set of instructions that helps a business user verify whether a Salesforce feature or process works as expected.

Each test case describes a specific business scenario, the steps required to complete it, and the expected outcome.

For example, imagine you’ve configured an approval process for sales discounts.

A useful UAT test case doesn’t simply tell someone to “test the approval process.”

It explains what the user needs to do, what information to enter, and what should happen when they submit a discount for approval.

That distinction matters.

UAT isn’t about proving that Salesforce works technically. It’s about confirming that your solution supports the way people actually need to work.

Unit testing and technical testing help verify that individual components and integrations function correctly. UAT focuses on whether the completed solution satisfies business requirements and is ready for its intended users.

When your test cases are clear, your testers know what to do, your project team gets more useful feedback, and everyone has a better understanding of what’s ready for deployment and what still needs attention.

What Makes a Good UAT Test Case?

A good UAT test case answers three simple questions:

1. What are we testing?
2. What should the user do?
3. What should happen when they do it?

That sounds straightforward. But it’s surprisingly easy to overlook important details.

When test cases are too vague, users make assumptions, skip steps, or interpret the expected results differently. And when something goes wrong, your project team may struggle to figure out whether there’s an actual defect or simply a misunderstanding.

The solution isn’t to write longer test cases. It’s to make them clearer.

The Essential Components of a UAT Test Case

Every test case should contain enough information for someone familiar with the business process to complete the test without needing constant guidance.

Here’s what I recommend including:

Component	What to Include
Test Case ID	A unique identifier so you can track and reference the test case.
Business Scenario	A brief description of the business process or functionality being tested.
Related Requirement	The business requirement or acceptance criterion the test case is intended to validate.
Tester or User Role	Who should perform the test and which Salesforce permissions or user role they need.
Prerequisites and Test Data	Any records, information, permissions, or conditions that need to exist before testing begins.
Test Steps	Clear instructions explaining what the tester should do.
Expected Result	What should happen when the steps are completed successfully.
Actual Result	What actually happened when the test was performed.
Test Status	Whether the test passed, failed, was blocked, or hasn’t been executed yet.
Defect Reference or Evidence	A link to the reported issue, screenshot, or supporting information when necessary.

You don’t necessarily need a sophisticated testing application to manage this information. Depending on your project’s complexity, a well-organized spreadsheet may be perfectly adequate.

The important thing is that your team has a consistent way to document what’s being tested and what happened.

Write Test Steps That Business Users Can Follow

Remember who’s doing the testing.

Your business users may understand their jobs extremely well, but that doesn’t mean they’re familiar with Salesforce configuration, automation, or technical terminology.

Avoid instructions that assume they know how the underlying system works.

For example, instead of telling a tester to “verify the approval automation,” explain which record to open, what action to take, and what result they should see.

Use the same terminology your users see on their screens whenever possible.

And don’t assume that something is obvious just because it’s obvious to you.

Make Expected Results Specific

One of the most common problems with UAT test cases is an expected result that simply says “works as expected.”

Expected by whom?

A useful expected result describes something the tester can actually observe and verify.

For example:

Too vague: The Opportunity should update correctly.

Better: After the user changes the Opportunity stage to Closed Won and saves the record, the stage should display Closed Won and the Close Date should reflect the date entered by the user.

The second version gives the tester something specific to check.

It also makes troubleshooting much easier when the actual result doesn’t match expectations.

Keep Your Test Cases Focused

It’s tempting to create one massive test case that walks through an entire business process from beginning to end.

Sometimes an end-to-end scenario is appropriate, especially when you’re validating how multiple steps or systems work together.

But don’t make every test case unnecessarily complicated.

Where practical, keep test cases focused on a clear business outcome. This makes them easier to execute, troubleshoot, and repeat after defects are corrected.

And remember, a passed test case doesn’t mean the entire Salesforce solution is ready to launch.

It means the specific scenario you tested behaved as expected.

That’s why choosing the right scenarios matters just as much as documenting them properly.

A Practical Salesforce UAT Test Case Example

Now that we’ve covered what belongs in a UAT test case, let’s put it into practice.

Imagine your sales team has a new requirement: any Opportunity with a discount greater than 20% must receive manager approval before moving to Closed Won.

Your Salesforce team has configured the approval process, and everything appears to be working.

But how do you know it works the way the business expects?

That’s where UAT comes in.

Instead of asking someone to “test the approval process,” we’ll create a test case that walks them through a specific business scenario.

Step 1: Document the Business Scenario

Let’s start with the basics.

Field	Example
Test Case ID	UAT-001
Test Case Name	Submit an Opportunity Discount for Manager Approval
Business Requirement	Opportunities with discounts greater than 20% require manager approval before moving to Closed Won.
Business Scenario	A sales representative requests approval for an Opportunity with a 25% discount.
Tester	Sales Representative
Priority	High
Test Environment	Salesforce UAT Sandbox
Test Status	Not Run

Notice that we’re not describing how the approval automation was built.

We’re describing what the business needs to accomplish.

That’s an important distinction.

Your testers don’t need to understand the technical configuration. They need to know whether the business process works.

Step 2: Identify the Prerequisites

Before testing begins, make sure everything the tester needs is available.

For this example, we’ll assume:

• The tester has access to the Salesforce UAT sandbox.
• A test Opportunity has been created.
• The tester has permission to edit the Opportunity and submit it for approval.
• The Opportunity includes a Discount Percentage field.
• The approval process has been configured to require manager approval for discounts greater than 20%.
• A designated sales manager is available to review the approval request.

These prerequisites matter.

If the tester doesn’t have the correct permissions or test data, they could report a failure that has nothing to do with the functionality being tested.

Good UAT starts before anyone clicks the first button.

Step 3: Write the Test Steps and Expected Results

Now we’ll document exactly what the tester should do.

Step	Action	Expected Result
1	Log in to the Salesforce UAT sandbox as the designated sales representative.	The user successfully accesses Salesforce.
2	Open the designated test Opportunity.	The Opportunity opens and displays the expected information.
3	Update the Discount Percentage field to 25% and save the record.	The Opportunity saves with the updated discount.
4	Submit the Opportunity for approval.	Salesforce accepts the submission and creates an approval request.
5	Confirm that the approval request was assigned to the designated manager.	The designated manager can access the pending approval request.
6	Attempt to move the Opportunity to Closed Won while approval is pending.	The configured approval controls prevent the Opportunity from moving to Closed Won without the required approval.
7	Have the designated manager approve the request.	The approval is recorded, and the Opportunity reflects the approved outcome according to the configured business rules.

For this example, we’re assuming the organization has configured the approval process and its supporting controls to produce these results. Your actual test steps should reflect your organization’s Salesforce configuration.

Notice how specific the expected results are.

We’re not simply saying that the approval process should work.

We’re identifying what should happen at each stage so the tester can confirm whether the system behaves as intended.

Step 4: Record What Actually Happened

During testing, the tester should document the actual outcome rather than simply checking a box and moving on.

For each step, they should compare what happened with the expected result.

If everything works correctly, the test case can be marked as Passed.

But what happens when something doesn’t work?

Suppose the tester submits the Opportunity for approval, but the approval request goes to the wrong manager.

The tester should document the issue clearly.

For example:

Field	Example
Test Case ID	UAT-001
Failed Step	Step 5
Expected Result	Approval request is assigned to the designated sales manager.
Actual Result	Approval request was assigned to a different manager.
Status	Failed
Defect Reference	BUG-014
Supporting Evidence	Screenshot of the approval request showing the incorrect approver.

This gives the project team something they can investigate.

Compare that with receiving feedback that says, “The approval process doesn’t work.”

Which one would you rather troubleshoot?

Step 5: Don’t Forget Negative Testing

So far, we’ve tested a scenario where the Opportunity should require approval.

But what about scenarios where approval shouldn’t be required?

For example, what happens when the discount is only 10%?

If the business requirement specifies that approval is needed only for discounts greater than 20%, you should also confirm that a 10% discount can proceed without that approval.

And what happens when the discount is exactly 20%?

That deserves its own test because the difference between “greater than 20%” and “20% or greater” matters.

Treat 10%, exactly 20%, and 25% as separate test scenarios so you can verify the approval threshold below, at, and above the boundary.

These are examples of negative and boundary testing.

They help uncover problems that might not appear when you’re only testing the most obvious successful scenario.

You should also consider situations such as:

• A user attempting an action without the required permissions.
• A required field being left blank.
• An approval request being rejected.
• A user attempting to bypass an approval requirement.

Not every scenario applies to every Salesforce implementation. Focus on the situations that matter to your business requirements and the risks you’re trying to reduce.

What This Example Teaches Us

A good UAT test case doesn’t need to be complicated.

It needs to be specific enough that a business user can execute it, understand the expected outcome, and document what happened.

And remember, your goal isn’t simply to prove that the Salesforce configuration works. It’s to confirm that the business process works as intended.

That’s what makes UAT valuable.

How to Create Your Own UAT Test Cases

You’ve seen what a good UAT test case looks like. Now let’s talk about how to create one for your own Salesforce project.

The process starts long before you write your first test step.

One of the biggest mistakes I see is treating UAT as something you figure out once development is finished.

By then, you’re often working against the clock, trying to pull together test scenarios while everyone is focused on getting the project launched.

A better approach is to think about testing while you’re defining the business requirements.

Here’s how I recommend approaching it.

Step 1: Start With Your Business Requirements

Before writing test cases, make sure you understand what the business actually needs the solution to accomplish.

Not what Salesforce is capable of doing. Not how the administrator or developer configured it.

What does the business need to happen?

For example, imagine your sales team wants to prevent Opportunities from moving to Closed Won unless certain information has been completed.

That’s a business requirement.

But it raises some important questions.

Which fields are required? Does the rule apply to every Opportunity? Are there exceptions? What should happen when someone attempts to save an incomplete record?

These details matter because they determine what you’ll need to test.

If your requirements are vague, your test cases will probably be vague, too. For additional guidance, see how to gather business requirements for a Salesforce project.

And if you discover that a requirement isn’t clear enough to test, that’s useful information. It means you need to revisit the requirement before moving forward.

Step 2: Identify Real-World Business Scenarios

Once you understand the requirements, think about how people will actually use the system.

Don’t limit yourself to the way the process is supposed to work when everything goes perfectly.

Talk to the people who perform these tasks every day.

Ask questions like:

• What are you trying to accomplish?
• What steps do you normally follow?
• What information do you need?
• What happens when something goes wrong?
• Are there exceptions to the normal process?
• Do other people or systems need to be involved?

You might discover that the process works differently depending on the customer’s location, the type of transaction, or the user’s responsibilities.

Those differences can become important test scenarios.

For example, a Salesforce workflow that works perfectly for a sales representative might behave differently for a sales manager with additional permissions.

Or an Opportunity that processes correctly when created manually might fail when information comes from an integrated system.

The closer your test scenarios reflect real business activities, the more useful your UAT results will be.

Step 3: Prioritize the Scenarios That Matter Most

Not every test scenario carries the same level of risk.

And unless you have unlimited time and resources, you probably won’t be able to test every possible combination.

That’s okay.

Your goal is to focus your testing effort where problems would have the greatest consequences.

Consider three factors:

Business impact: What happens if this process fails? Could it prevent someone from doing their job, delay a customer transaction, or create financial problems?

Likelihood: How likely is the scenario to occur? Is it something users do dozens of times a day, or an unusual exception?

Complexity: Does the process involve multiple systems, complicated business rules, or different types of users?

For example, testing an integration that creates customer invoices might deserve higher priority than verifying the placement of a rarely used field.

That doesn’t mean the smaller issue should be ignored.

It means you should make deliberate decisions about where to focus your limited testing time.

Step 4: Turn Each Scenario Into Clear Test Steps

Once you’ve identified your scenarios, it’s time to document the individual test cases.

Use the structure we covered earlier:

• Identify the business scenario and related requirement.
• Specify who should perform the test.
• Document any prerequisites or necessary test data.
• Write the steps the tester should follow.
• Define the expected result.
• Provide a way to record actual results and report problems.

Keep the instructions straightforward.

Someone who understands the business process should be able to follow the steps without needing you to explain what you meant.

And wherever possible, describe the expected results in terms of what users can actually see or experience.

For example, don’t write “Confirm the Flow executed successfully.”

Instead, describe the business outcome the Flow is supposed to produce.

Your testers shouldn’t need to understand Salesforce automation to determine whether their business process works.

Step 5: Prepare Realistic Test Data and User Access

Even well-written test cases can produce misleading results when the testing environment doesn’t reflect how people actually work.

Before testing begins, make sure your scenarios have the appropriate data and user access.

For example, if you’re testing an Opportunity approval process, you’ll need Opportunities with the relevant discount amounts and users with the appropriate roles and permissions.

If you’re testing a process involving Accounts and Contacts, you’ll need records that represent realistic customer relationships.

And if a workflow depends on an external integration, you’ll need to establish how that integration will be tested safely.

Use appropriate test data, and avoid exposing sensitive production information unnecessarily.

Also, remember that testing everything as a Salesforce System Administrator can hide permission problems.

A process that works for an administrator may fail for the person who’s actually supposed to use it.

That’s why testing with the appropriate user permissions is so important.

Step 6: Review Your Test Cases With Business Users

Before handing your test cases to the testing team, ask someone familiar with the business process to review them.

Ideally, this should include people who will actually use the solution.

Ask them to look for missing steps, unclear instructions, unrealistic assumptions, and scenarios you might have overlooked.

You may discover that your test cases technically cover the requirements but miss an important part of the user’s everyday workflow.

That’s exactly the kind of issue you want to uncover before testing begins.

And don’t treat this review as a formality.

Give people permission to challenge your assumptions.

If a business user says, “That’s not how we actually do this,” you’ve probably learned something important.

Before You Begin Testing

Once your test cases are written and reviewed, make sure they’re ready for execution.

You should be able to answer a few basic questions:

• Does each test case connect to a business requirement?
• Are the steps clear enough for the intended tester?
• Are the expected results specific and measurable?
• Is the necessary test data available?
• Have you accounted for important exceptions and failure scenarios?
• Does someone own the responsibility for performing each test?

If you can answer those questions confidently, you’re in a much better position to begin UAT.

Remember, the goal isn’t to create the largest possible collection of test cases. It’s to create the right test cases to help your business make an informed decision about whether the solution is ready.

Common UAT Mistakes and How to Avoid Them

Even experienced Salesforce teams make mistakes during user acceptance testing.

Sometimes it’s because everyone is rushing to meet a deadline. Other times, it’s because the team assumes that if the configuration works, the business process must work too.

Unfortunately, those assumptions can lead to unpleasant surprises after deployment.

Let’s look at some common mistakes and how to avoid them.

Mistake 1: Treating UAT Like a Quick Sanity Check

You’ve finished building a new Salesforce feature, and someone suggests having a few users “play around with it” before launch.

What could go wrong?

Plenty.

Without clear test cases, users tend to explore the parts of Salesforce they’re already comfortable with. They might overlook important scenarios, skip complicated processes, or miss something simply because they didn’t know what to look for.

And when someone says, “Everything looks good,” what does that actually tell you?

Not much.

What to do instead: Give testers specific business scenarios, clear instructions, and expected outcomes. Allow time for exploratory testing, too, but don’t treat it as a substitute for structured UAT.

Mistake 2: Waiting Until the Last Minute

UAT often gets squeezed between development and deployment.

The project is running behind schedule, leadership wants a launch date, and suddenly everyone is expected to complete testing in a fraction of the time originally planned.

That’s a problem.

When testing becomes a last-minute activity, teams may rush through scenarios, overlook defects, or decide that unresolved issues aren’t worth delaying the launch.

What to do instead: Plan for UAT early in the project. Identify who needs to participate, reserve time on their calendars, and account for defect resolution and retesting.

Remember, finding a problem is only useful if you have enough time to address it.

Mistake 3: Testing Only When Everything Goes Right

It’s easy to focus on successful scenarios.

A user creates a record. The record saves. The automation runs. Everyone’s happy.

But real users don’t always follow the ideal process.

They forget required information. They enter unexpected values. They perform tasks in a different order. They encounter exceptions that weren’t part of the original demonstration.

And sometimes, they try to do things they shouldn’t have permission to do.

What to do instead: Include negative testing, boundary conditions, and important exceptions.

For example, if Salesforce requires manager approval for discounts greater than 20%, test discounts below, at, and above that threshold.

You want to know what happens when users encounter the boundaries of your business rules, not just when everything goes according to plan.

Mistake 4: Confusing Technical Testing With Business Acceptance

Your developers have tested their code. Your administrator has verified the Flow. Your integration tests passed.

So why do you still need UAT?

Because those tests don’t necessarily confirm that the solution meets the business’s needs.

A Flow might execute exactly as configured while still producing an outcome that doesn’t support the intended business process.

For example, Salesforce might successfully send an approval notification, but to the wrong person.

Technically, the automation ran. From the business’s perspective, the process failed.

What to do instead: Keep UAT focused on business requirements, user workflows, and expected outcomes.

Technical testing and UAT complement one another. Neither replaces the other.

Mistake 5: Accepting Vague Defect Reports

You’ve probably received feedback like this:

“It doesn’t work.”

Or my personal favorite:

“Salesforce is broken.”

That’s not particularly helpful.

Without knowing what the tester was doing, what they expected, and what actually happened, your project team has very little information to work with.

Someone then has to contact the tester, ask questions, reproduce the problem, and determine whether it’s a defect, a training issue, or a misunderstanding.

That’s time nobody needed to waste.

What to do instead: Establish a simple process for documenting defects.

At a minimum, ask testers to provide the affected test case, steps to reproduce the problem, expected result, actual result, and relevant screenshots or error messages.

Not every unexpected result is a software defect. Good documentation helps your team determine what’s actually happening.

Mistake 6: Fixing Defects Without Retesting

Here’s a familiar scenario.

A tester identifies a problem. The Salesforce team investigates and makes a correction. Someone updates the defect status to “Fixed.”

Problem solved, right?

Not necessarily.

Just because someone changed the configuration doesn’t mean the issue has been resolved from the user’s perspective.

And occasionally, fixing one problem introduces another.

What to do instead: Have the appropriate tester verify that the original issue is resolved. When the change could affect related functionality, include regression testing.

Don’t confuse “we made a change” with “the problem is fixed.”

Mistake 7: Treating UAT Sign-Off as a Formality

You’ve completed testing. Most test cases passed. A few issues remain, but everyone is eager to launch.

So someone asks the business sponsor to sign off.

Unfortunately, a signature doesn’t magically eliminate unresolved problems.

Before approving deployment, the people responsible for accepting the solution should understand what’s been tested, what hasn’t, and which issues remain unresolved.

They also need to understand the potential business impact of those issues.

What to do instead: Establish clear acceptance criteria and a process for making the go-live decision.

Review testing results, outstanding defects, and any agreed-upon workarounds with the appropriate business stakeholders.

Some issues may be acceptable to address after deployment. Others may create too much risk.

The important thing is to make that decision deliberately, with the right people involved.

The Common Thread

Notice what these mistakes have in common?

Most aren’t caused by a lack of Salesforce knowledge.

They’re caused by unclear expectations, poor communication, insufficient planning, or assumptions about what testing is supposed to accomplish.

That’s why effective UAT requires more than technical skills.

You’re not just testing Salesforce. You’re helping the business decide whether the solution is ready to support the people who depend on it.

And that decision deserves more than a few hurried clicks and a thumbs-up.

Preparing for and Executing UAT

You’ve written your test cases, reviewed them with stakeholders, and identified the scenarios that need to be tested.

Now it’s time to put your Salesforce solution to the test.

But before you invite everyone to start clicking around, there are a few things worth getting organized.

Successful UAT requires more than a collection of test cases. You need the right environment, the right people, and a clear process for handling what happens when something doesn’t work.

Here’s how to approach it.

1. Make Sure Your Testing Environment Is Ready

Your Salesforce sandbox should be ready before testing begins.

That sounds obvious, but it’s surprisingly common for testers to encounter problems caused by an incomplete testing environment rather than the functionality they’re supposed to evaluate.

Before starting UAT, verify that:

• The functionality being tested has been deployed to the appropriate sandbox.
• Test users have the permissions they need.
• Relevant test records and supporting data are available.
• Required integrations are configured for safe testing, where applicable.
• Any necessary email notifications, approval processes, and automation are functioning.
• Testers know how to access the environment.

Pay particular attention to integrations.

If your Salesforce process depends on another application, you need to understand how that connection will behave during testing.

You don’t want someone accidentally sending test transactions to a production accounting system or triggering real customer notifications.

And remember, a sandbox isn’t automatically a perfect replica of production.

Differences in data, permissions, integrations, and configuration can affect your results.

Make sure your testing environment supports the scenarios you’re asking people to validate.

2. Assign Test Cases to the Right People

Not everyone needs to test everything.

In fact, asking every participant to work through every test case can create unnecessary confusion and duplicate effort.

Instead, assign test cases based on the business processes people understand and the responsibilities they perform.

For example:

A sales representative might test creating Opportunities and submitting discount requests.

A sales manager might test reviewing and approving those requests.

Someone from Finance might validate that approved transactions contain the information needed for invoicing.

Each person brings a different perspective.

And that’s exactly what you want.

The people who understand the business process are often the best people to recognize when something isn’t working as intended.

Make sure each tester understands which scenarios they’re responsible for, when testing needs to be completed, and how to report problems.

3. Give Testers a Simple Way to Track Progress

You don’t necessarily need an expensive testing platform to manage UAT.

For smaller Salesforce projects, a shared spreadsheet may be sufficient.

For larger initiatives, you may benefit from a dedicated testing or project-management application.

Either way, you need visibility into what’s happening.

At a minimum, each test case should have a status.

Status	What It Means
Not Run	Testing hasn’t started.
In Progress	The tester has started executing the test case.
Passed	The actual results match the expected results.
Failed	One or more expected results were not achieved.
Blocked	The tester cannot complete the test because of another issue or dependency.

Keep these definitions consistent.

For example, if a tester can’t access Salesforce because their account hasn’t been configured, that test case is blocked.

It hasn’t failed because the business functionality is defective. The tester simply couldn’t complete it.

That distinction matters when you’re evaluating the results.

You should also track who owns each test case, when it was executed, and any associated defects.

The goal isn’t to create more administrative work.

It’s to make sure everyone understands what’s been tested, what still needs attention, and what’s preventing progress.

4. Establish a Process for Managing Defects

Eventually, someone is going to find something that doesn’t work.

That’s not necessarily a bad thing.

Finding problems before deployment is one of the reasons you’re conducting UAT in the first place.

What matters is how your team responds.

When a tester reports an issue, someone needs to review it and determine what happens next.

Is it a genuine defect? A misunderstanding of the requirement? A permissions issue? Or perhaps a new requirement that nobody identified earlier?

Those situations may require different responses.

I recommend establishing a simple process:

Document the issue. Capture what happened, what was expected, and how to reproduce the problem.

Review and classify it. Determine whether it’s a defect, a configuration issue, a training concern, or a potential change request.

Evaluate the impact. Consider how seriously the issue affects the business process and how urgently it needs attention.

Assign responsibility. Make sure someone owns the investigation and resolution.

Retest the solution. Once a correction has been made, confirm that the issue is actually resolved.

One important distinction: severity and priority aren’t necessarily the same thing.

Severity describes how significantly the issue affects the system or business process.

Priority reflects how urgently the team needs to address it.

A minor issue affecting a critical business deadline might deserve immediate attention. Meanwhile, a serious defect in functionality that won’t be used until a later phase may have a different resolution timeline.

Make these decisions based on business impact, not simply how complicated the technical problem appears.

5. Make Time for Retesting

Finding defects is only part of UAT.

You also need to verify that the corrections work.

Suppose a tester discovers that an Opportunity approval request is being assigned to the wrong manager.

Your Salesforce administrator investigates the issue, updates the configuration, and marks the defect as resolved.

Before closing the issue, the tester should repeat the relevant steps and confirm that the approval request now goes to the correct person.

Depending on the change, you may also need to test related functionality.

For example, correcting an approval rule could affect other scenarios that use the same automation.

This is where regression testing becomes important.

The goal is to confirm that the correction resolved the original problem without introducing new issues into existing processes.

Don’t treat a defect as resolved simply because someone says they’ve fixed it. Verify the result.

6. Review the Results Before Making the Go-Live Decision

Eventually, the project team needs to decide whether testing is complete and the solution is ready for deployment.

This shouldn’t be based solely on the percentage of test cases that passed.

Imagine that 98% of your tests passed.

That sounds encouraging.

But what if the remaining 2% involve a critical integration that prevents customer invoices from being created?

Would you consider the solution ready?

Probably not.

Now consider a different situation.

A small formatting issue remains unresolved in a rarely used report, but all critical business processes have passed testing.

That might be an acceptable issue to address after deployment.

The difference is business risk.

Before making the go-live decision, review:

• Whether the agreed-upon test scenarios have been completed.
• Whether critical business processes passed.
• Which defects remain unresolved.
• The business impact of those outstanding issues.
• Whether acceptable workarounds exist.
• Whether any additional testing is required.
• Whether the appropriate business stakeholders are comfortable accepting the remaining risks.

Ideally, these acceptance criteria should have been established before UAT began.

That way, everyone understands what successful testing looks like rather than trying to define success after seeing the results.

7. Obtain Business Sign-Off

UAT isn’t complete simply because the Salesforce team believes the solution is ready.

The appropriate business stakeholders need to review the results and formally accept the solution.

That doesn’t necessarily require a complicated approval process.

Depending on the project, sign-off might involve an approval in your project-management system, a documented decision from the business sponsor, or a formal acceptance document.

What matters is that the decision is clear and recorded.

The business should understand which requirements were validated, what issues remain, and what risks they’re accepting.

And if critical problems remain unresolved, those concerns should be addressed rather than buried in a testing summary.

Business sign-off should reflect an informed decision, not pressure to meet a launch date.

Remember What UAT Is Really About

It’s easy to become focused on test execution statistics, defect counts, and completion deadlines.

Those things are useful, but they’re not the ultimate goal.

You’re trying to determine whether the Salesforce solution is ready to support the people and processes it was designed for.

That’s why good UAT requires collaboration between technical teams, business users, project leaders, and decision-makers.

When everyone understands their responsibilities and works toward the same outcome, testing becomes much more than a box to check before deployment.

It becomes a meaningful part of delivering a successful Salesforce project.

Salesforce UAT Test Case Checklist

Before you hand your test cases to your business users, take a few minutes to make sure everything is ready.

You don’t need a complicated review process. But a little preparation now can save your team considerable frustration once testing begins.

Use this checklist to catch potential problems before they slow everyone down.

Business Requirements and Test Coverage

Test Case Quality

Testing Readiness

Defect Management and Business Acceptance

Ready to Begin?

If you’ve checked everything on this list, you’re in a good position to start testing.

If something is missing, address it before it becomes a problem.

Not every Salesforce project needs an elaborate UAT process. A small configuration change might require only a handful of focused test cases, while a major implementation involving multiple departments and integrations will need considerably more preparation.

The goal isn’t to make UAT complicated. It’s to make sure your testing gives the business enough confidence to make an informed decision.

Final Thoughts: Better UAT Starts With Better Test Cases

Successful Salesforce projects aren’t just about building the right functionality. They’re about making sure that functionality actually works for the people who depend on it.

And that’s where effective user acceptance testing makes a difference.

You don’t need complicated testing tools, hundreds of test cases, or an elaborate process to get started.

You need clear business requirements, realistic scenarios, meaningful expected results, and people who understand how the business actually operates.

Most importantly, you need to approach UAT as an opportunity to learn what’s working and what still needs attention, not simply as another task to complete before launch.

A good UAT test case doesn’t just tell you whether something works. It helps you understand whether it works the way your business needs it to.

So, before your next Salesforce deployment, take another look at your test cases.

Are they clear? Are they realistic? Would someone unfamiliar with the configuration understand exactly what to do and what to expect?

If you’re not sure, start with the example and checklist in this guide.

A little extra effort preparing your test cases can save considerable frustration when it’s time to put your Salesforce solution into the hands of your users.

And that’s time well spent.