UAT Testing for Salesforce: A Practical Guide for Implementation Teams

Salesforce implementations have a reputation for going live on time and then quietly failing over the following six months. The sales team ignores half the features. The forecast data is wrong. Service agents create workarounds rather than using the system as designed. Most of this is preventable, and the prevention happens during UAT, if UAT is done properly.

This guide is for implementation teams running UAT on Salesforce Sales Cloud, Service Cloud, or the broader Salesforce platform. It covers what to test, how to structure your approach, the Salesforce-specific failure modes that trip up most projects, and how to get genuine sign-off rather than a reluctant tick in a box.

1. Why Salesforce UAT Is Harder Than It Looks

Salesforce presents a deceptive testing challenge. The platform looks clean, the sandbox environments are easy to spin up, and the low-code configuration model means most customisations can be built quickly. This creates a false sense of security. The real complexity in Salesforce UAT comes from three sources.

• Salesforce is infinitely configurable: the same Sales Cloud product looks completely different from one org to the next. Page layouts, record types, validation rules, required fields, and Flows are all organisation-specific. A test script written for one Salesforce project will not work for another. Your tests must reflect exactly how your specific org has been configured
• Profiles and permissions are complex and easy to misconfigure: a sales rep with the wrong profile will see a different page layout to the one you tested. A service agent missing a permission set will not be able to update case fields that the admin can update fine. UAT must be executed by users logged in with their actual assigned profiles, not as system administrators
• Business users resist structured testing: sales teams in particular view testing as an interruption to their selling. They will click through test scripts as fast as possible, mark things as passed, and move on. If your testing approach does not account for this reality, your UAT results will be worthless

2. What to Test in Salesforce Sales Cloud

Sales Cloud testing needs to follow the commercial process from first contact through to closed-won and beyond. Testing features in isolation will miss the issues that matter.

Lead Management

• Lead creation and assignment: create leads via web-to-lead forms, manual entry, and data import. Validate that lead assignment rules route records to the correct queues and owners
• Lead qualification and conversion: convert a lead and confirm that the resulting account, contact, and opportunity records are created correctly with the correct field values carried across
• Duplicate management: attempt to create duplicate records and confirm that duplicate rules and matching rules trigger correctly

Opportunity Pipeline

• Stage progression: move an opportunity through each pipeline stage and verify that entry criteria, validation rules, and any required fields enforce the correct business rules at each transition
• Products and price books: add products to opportunities and confirm that pricing, discounts, and totals calculate correctly against the correct price book
• Opportunity teams and sharing: assign opportunity team members and confirm that sharing rules give them the correct level of access to the record and related objects
• Closed-won and closed-lost processes: test the full close process including any automation that triggers on close, such as onboarding tasks, contract creation, or notifications

Quote-to-Cash (if in scope)

• CPQ or native quoting: generate a quote from an opportunity and validate that line items, pricing rules, discounts, and approval thresholds all behave correctly
• Quote approval workflows: submit a quote requiring approval and verify that the approval process routes correctly, that the approver receives notification, and that approval or rejection updates the quote and opportunity correctly
• Contract creation and activation: if using Salesforce Contracts, test that contracts are generated from won opportunities with the correct terms and that activation triggers any downstream processes

Forecasting

• Forecast categories: confirm that opportunities appear in the correct forecast categories based on their stage and that forecast amounts calculate correctly
• Manager hierarchy roll-up: verify that forecast figures roll up correctly through the sales management hierarchy
• Forecast adjustments: test that managers can make forecast adjustments and that those adjustments are visible and attributed correctly

Email and Calendar Integration

• Outlook or Google Workspace sync: test that emails logged via the Salesforce integration appear correctly on the relevant contact and opportunity records. Confirm that calendar events sync bidirectionally
• Activity logging: verify that calls, emails, and tasks logged by sales reps appear correctly on the activity timeline and roll up to account and opportunity records

Mobile App

If your sales team will use the Salesforce mobile app, test the critical journeys on the actual device types they use. Mobile layouts, required fields, and offline behaviour can differ significantly from the desktop experience, and these differences are routinely discovered only after go-live.

Dashboards and Reports

• Key sales reports: run the pipeline report, activity report, and forecast report using test data created during UAT. Confirm that figures are accurate and that filters return the expected records
• Sales manager dashboards: open dashboards as a sales manager and confirm that the data visible reflects only the records within their team visibility, not the entire org

3. What to Test in Salesforce Service Cloud

If Service Cloud is in scope, testing needs to cover the full case lifecycle and the routing and SLA mechanics that sit behind it. Service Cloud failures tend to surface as operational problems rather than technical errors, making them harder to trace back to root cause after go-live.

Case Management

• Case creation channels: test case creation via email-to-case, web-to-case, and manual entry. Validate that cases are created with the correct fields populated based on the incoming channel
• Case status lifecycle: move a case through each status and verify that validation rules, required fields, and automation fire correctly at each transition
• Case escalation: trigger an escalation rule manually and confirm that the case owner, priority, and notifications update correctly
• Case closure and reopen: close a case and confirm the closure survey or notification fires. Reopen the case and confirm it moves back to the correct status with appropriate logging

Routing and Assignment

• Assignment rules: create cases that should trigger each assignment rule and confirm routing to the correct queue or agent
• Omni-Channel routing: if using Omni-Channel, test that work items route to agents with the correct skills and capacity. Confirm that agents in different statuses (Available, Busy, Away) receive or do not receive work correctly
• Queue management: validate that agents can accept, decline, and transfer cases from queues, and that transfer rules work correctly

SLAs and Entitlements

• Entitlement assignment: create cases for accounts with entitlements and confirm that the correct entitlement is applied and that SLA milestones are created
• SLA breach warnings: allow a milestone to approach its deadline and confirm that warning notifications fire at the configured threshold
• SLA reporting: run entitlement and SLA reports and confirm that first response and resolution time metrics are calculated correctly

Knowledge Articles

• Article creation and approval: create a knowledge article and submit it through the publication approval process. Confirm the article appears in the correct category and is visible to the intended audience after publication
• Article search from cases: open a case and search for a related knowledge article. Confirm that the search returns relevant results and that attaching an article to a case logs correctly

4. Salesforce-Specific UAT Challenges

Beyond the process-level testing above, Salesforce implementations have specific technical areas that cause disproportionate problems during and after UAT.

5. Getting Sales Reps to Actually Do UAT

This is, genuinely, the hardest part of any Salesforce implementation. Sales reps are measured on revenue, not on testing thoroughness. Asking them to spend two weeks executing test scripts is asking them to stop doing the thing they are paid to do. If you approach it wrong, you will get superficial testing, false pass results, and a go-live that looks approved but is not.

Frame Testing as Training

Sales reps are much more willing to engage with testing when it is framed as getting familiar with the new system rather than quality assurance. UAT is, in practice, the best pre-go-live training you can offer. A rep who has executed twenty test cases in the sandbox before go-live will be far more productive on day one than one who attended a one-hour demo.

Keep Test Cases Short and Scenario-Based

Sales reps do not respond well to long, technical test scripts. Write short, scenario-based test cases that mirror their actual daily workflow. Instead of "Navigate to Opportunity object and create a new record with the following field values", write "You have a new prospect from the trade show. Create the lead, qualify it, and convert it to an opportunity with a first meeting booked." The outcome is the same. The engagement is completely different.

Get Sales Leadership Involved Early

If the VP of Sales or Sales Director is visibly invested in UAT, the team will take it seriously. Get a senior sales leader to co-own the testing sign-off. Brief them on the consequences of an inadequate test, specifically the forecast accuracy problems, data quality issues, and adoption failures that follow poorly tested Salesforce implementations. Make it clear that their name is on the sign-off.

Time-Box Testing Sessions

Rather than asking reps to fit testing around their normal day, block two to three dedicated testing sessions of ninety minutes each. Have a Salesforce admin or consultant in the room to answer questions and triage defects in real time. This concentrated approach produces better results than two weeks of sporadic, unmonitored testing.

6. Sign-Off for Salesforce: Who Approves and What They Confirm

Salesforce UAT sign-off needs to be structured around the business functions that use the platform, not just the technical configuration. For a standard Sales Cloud and Service Cloud implementation, the sign-off structure should cover four areas.

Defining Sign-Off Criteria Upfront

Before UAT begins, agree on what sign-off actually means. The criteria should be explicit and written down. A reasonable baseline for Salesforce is:

• All critical and high-severity test cases have passed, with defects resolved and retested by the original tester
• All user profiles have been tested by actual users with those profiles, not by admins
• Data migration has been validated by processing real business transactions against migrated records
• All integrations have been tested end-to-end in the UAT environment with real credentials
• Medium-severity defects have documented workarounds and a committed post-go-live fix date

7. How LogicHive Helps with Salesforce UAT

Most Salesforce UAT is managed in spreadsheets. A shared Excel file tracking test cases, a separate sheet for defects, and a weekly status update email that nobody fully trusts. It works, barely, on small projects. On anything of meaningful scale, it creates visibility gaps, missed retests, and sign-off decisions made with incomplete information.

LogicHive gives Salesforce implementation teams a centralised platform for the entire UAT process. Test cases are written, assigned, and tracked in one place. Defects are logged directly against test cases with no manual cross-referencing. Real-time dashboards show execution progress, pass rates, and outstanding defects by severity, so project managers and stakeholders always know where UAT stands without chasing status updates.

Critically, LogicHive has no per-seat fees for client-side testers. On a Salesforce project where you need twenty sales reps to execute test cases, per-seat pricing models make UAT tools prohibitively expensive. With LogicHive, you can invite as many testers as the project needs for a flat monthly fee from £72.99.

For more on how LogicHive supports Salesforce testing specifically, see our Salesforce testing platform page. For a full overview of features, see the LogicHive features page.