Enterprise Systems • Salesforce • GTM Operations • Business Transformation

In enterprise technology programs, User Acceptance Testing is often treated as one of the final boxes to check before deployment.

Requirements are approved. Development is complete. QA has tested the build. Jira tickets are moving toward Done. The project plan says UAT begins Monday.

Then the business discovers that the system technically works — but the process does not.

That distinction is where major implementations get into trouble.

After more than a decade working across Salesforce, GTM systems, business analysis, CPQ, revenue operations, and enterprise transformation, I have come to view UAT very differently:

UAT is not simply the final testing phase. It is the last opportunity to determine whether technology will actually survive contact with the business.

And on a complex enterprise implementation, that makes UAT one of the most important risk-control mechanisms in the entire delivery lifecycle.

QA Can Tell You the System Works. UAT Tells You Whether the Business Works.

Quality Assurance and User Acceptance Testing serve different purposes.

QA may validate that:

a Salesforce Flow executes correctly;
a validation rule fires under the expected condition;
a field updates properly;
an API responds successfully;
a pricing rule calculates the expected result;
a permission set grants the correct access;
a Lightning component behaves as designed.

All of that is important.

But UAT asks a larger question:

Can a real user complete a real business process successfully from beginning to end?

Consider a Salesforce CPQ implementation.

A developer may confirm that a discount approval rule works.

That does not necessarily tell us whether a sales representative can:

identify the correct account and opportunity;
select the appropriate products;
configure a valid bundle;
apply an allowable discount;
trigger the correct approval path;
generate the quote;
send the agreement through DocuSign;
successfully transfer the transaction downstream;
and ultimately allow Finance, Operations, and the customer to receive what they expect.

Those are very different standards of success.

The first verifies functionality.

The second verifies business continuity.

The Most Dangerous Defects Are Often Process Defects

One of the biggest misconceptions about UAT is that testers are primarily hunting for software bugs.

Sometimes they are.

But many of the highest-risk issues uncovered during UAT are actually failures in requirements, process design, data, governance, permissions, or integrations.

For example:

A user may successfully create a quote but discover that the approval path does not reflect actual discount authority.

That may not be a coding defect.

It may be a governance defect.

A quote may successfully transfer to an ERP, but a required value is missing downstream.

That may not be an integration defect.

It may be a requirements defect.

A salesperson may technically have access to a workflow but be unable to complete it without information owned by Finance.

That may not be a Salesforce problem.

It may be a process ownership problem.

This is why I consider UAT a continuation of business analysis rather than a separate testing activity.

Testing frequently reveals assumptions that requirements workshops missed.

Good UAT Begins Long Before UAT

The strongest UAT programs do not begin when development finishes.

They begin during requirements discovery.

If I’m building requirements for a business process, I’m already thinking about how that requirement will eventually be validated.

That means connecting:

Business Objective → Process Map → Requirement → User Story → Acceptance Criteria → Configuration → Test Scenario → Business Outcome

If that traceability is weak, testing becomes chaotic.

A Jira story such as:

As an Account Executive, I want discounts above 20% routed for approval.

sounds reasonable.

But good analysis asks:

20% relative to which price?
Is the threshold the same globally?
Does product family matter?
Are renewals treated differently?
What about strategic customers?
What if multiple discounts exist on the same quote?
Does approval change based on total contract value?
Can an approver delegate authority?
What happens if the quote changes after approval?
Does the approval reset?
Does the rule apply to amendments?
Who owns the policy?

Those questions ultimately become test conditions.

If they aren’t discussed during discovery, UAT becomes the first time the organization realizes the requirement was incomplete.

At that point, the project is already approaching deployment.

That’s an expensive time to discover ambiguity.

I Prefer Scenario-Based Testing Over Button Testing

One principle I bring into UAT is simple:

Test the business scenario, not just the feature.

A weak test case might say:

Click Submit for Approval and verify that the manager receives the request.

That confirms functionality.

A stronger scenario might say:

Create a multi-year enterprise opportunity containing multiple products, apply a non-standard discount requiring Finance approval, modify the quote after initial approval, resubmit it, generate the final document, and confirm the resulting transaction successfully reaches the downstream system.

Now we’re testing something much closer to production reality.

This becomes especially important in Salesforce and Quote-to-Cash environments because business processes are rarely linear.

Real transactions contain exceptions.

A mature UAT library should therefore test multiple dimensions:

happy paths;
negative scenarios;
boundary conditions;
exception workflows;
permission differences;
data dependencies;
integration failures;
amendments;
renewals;
multi-year transactions;
approval thresholds;
geographic differences;
product variations;
customer segments;
channel transactions;
and downstream financial consequences.

The goal isn’t simply high test volume.

The goal is meaningful coverage of business risk.

The Happy Path Is Usually the Easy Part

Most systems can handle the expected transaction.

The more interesting questions occur when reality does something unexpected.

What happens when:

the wrong approver is unavailable?
a sales representative changes a quote after approval?
a contract starts in the future?
a customer expands halfway through the term?
the transaction contains products with different billing models?
an integration temporarily fails?
ERP rejects the order?
required customer information is incomplete?
a user has the wrong permission?
a territory changes during the transaction?
the customer requires an unusual contractual structure?

Those are the cases that separate a demo-ready system from a production-ready system.

When I supported enterprise Salesforce and CPQ initiatives, including my work as a Senior Business Systems Analyst within Johnson & Johnson / Shockwave Medical, UAT required much more than confirming whether a screen loaded or a field populated.

It required understanding the end-to-end revenue process.

Salesforce might be where the transaction begins.

But successful testing may involve Salesforce CPQ, approvals, DocuSign, Oracle or another ERP, revenue operations, Sales Operations, Finance, and downstream teams.

That broader perspective matters.

UAT Is Where Process Maps Meet Production Reality

Process mapping is another important part of effective testing.

Before writing a test scenario, I want to understand the workflow visually.

A current-state or future-state process map might show:

Opportunity → Quote → Approval → Contract → Order → Billing

But underneath that simple diagram can exist dozens of decision points.

Using tools such as Lucidchart, Visio, Miro, Jira, Confluence, or similar platforms, a Senior Business Systems Analyst can map:

decision gates;
system boundaries;
roles and responsibilities;
manual interventions;
integration touchpoints;
exception paths;
approvals;
dependencies;
and handoffs.

Those process maps can then become the foundation for test scenarios.

This creates an important discipline:

Every important branch in the business process should have a corresponding validation strategy.

If your process map shows five critical exception paths and your UAT only tests the happy path, you do not have meaningful coverage.

You have optimism.

Jira Should Support UAT — Not Become UAT

Jira is extremely useful for managing enterprise delivery.

Epics, stories, subtasks, acceptance criteria, defects, priorities, dependencies, and release planning all create structure.

But Jira alone does not guarantee strong UAT.

I’ve seen programs where hundreds of Jira tickets existed, yet nobody could confidently answer:

Have we tested the complete business process?

That happens because tickets tend to fragment the implementation.

One story covers pricing.

Another covers approvals.

Another covers permissions.

Another covers integration.

Another covers reporting.

Each ticket can pass independently while the end-to-end workflow still fails.

That is why I prefer maintaining traceability between:

requirements;
Jira stories;
acceptance criteria;
business processes;
test scenarios;
defects;
retests;
and release readiness.

Sometimes that exists in Jira.

Sometimes Jira is paired with Confluence, spreadsheets, a test management platform, or another QA/UAT tool.

The tooling matters less than the discipline.

The real question is:

Can we prove that every critical business requirement has been validated?

UAT Is Also a Data Exercise

Another underestimated source of UAT failure is test data.

A perfectly designed test case becomes useless if the underlying data does not resemble production conditions.

In Salesforce, that can include:

accounts;
opportunities;
products;
price books;
currencies;
customer types;
territories;
contracts;
subscriptions;
discount schedules;
approval thresholds;
historical transactions;
user roles;
and permission structures.

Testing with overly clean or simplified data creates false confidence.

Production data is rarely clean.

Enterprise environments contain:

legacy records;
duplicates;
unusual account structures;
missing fields;
grandfathered contracts;
product migrations;
exceptions accumulated over years.

UAT needs enough realism to expose how the system behaves under those conditions.

Otherwise, you’re testing the environment you wish existed rather than the one your users actually operate in.

Permissions Can Break an Otherwise Perfect System

One of the classic testing mistakes is executing every scenario using an administrator profile.

Of course the process works.

The administrator can access everything.

The real question is whether the actual user persona can complete the process.

Testing should consider:

Account Executive;
Sales Manager;
Deal Desk;
Finance;
Sales Operations;
Revenue Operations;
Customer Support;
regional users;
integration users;
delegated approvers;
system administrators.

Salesforce permission sets, profiles, role hierarchy, sharing rules, field-level security, record ownership, and object permissions can dramatically change user behavior.

A workflow that succeeds for the project team can still fail immediately when deployed to 2,000 users.

That is why role-based testing is not optional.

UAT Is a Change Management Signal

There is another benefit to UAT that is often overlooked.

It tells you whether the organization is ready.

If testers repeatedly misunderstand a process, that may indicate a training problem.

If every tester follows a different workflow, that may indicate a process governance problem.

If users keep requesting workarounds, that may indicate poor adoption.

If testers refuse to use the future-state process and keep reverting to spreadsheets, email, or Slack, that’s telling you something.

Those aren’t simply testing observations.

They are change management signals.

A strong BSA should recognize them.

The project may need:

updated enablement;
better documentation;
clearer SOPs;
revised process maps;
improved system messaging;
additional training;
better stakeholder communication;
or even changes to the solution itself.

Testing becomes an early warning system for adoption.

Defect Triage Is a Business Decision

Not every UAT defect should block deployment.

That’s where judgment becomes important.

A mature defect triage process evaluates:

Severity — How serious is the problem?

Business Impact — What process or revenue activity does it affect?

Frequency — How often will the scenario occur?

Workaround — Is there a safe temporary alternative?

Data Impact — Could the issue corrupt or misstate information?

Financial Impact — Could it affect pricing, billing, booking, or revenue?

Regulatory / Compliance Impact — Does the issue introduce legal or control risk?

Dependency Impact — Could it break another system or process?

Release Risk — Is the fix riskier than the defect?

This is where cross-functional collaboration becomes critical.

Developers may understand technical complexity.

QA may understand reproducibility.

The BSA understands business intent.

Product owners understand priorities.

Operations understands the field reality.

Leadership understands risk tolerance.

Release decisions require all of those perspectives.

A Bug Is Not Closed When Development Says It Is Fixed

Another discipline I consider important is retesting.

Development resolving a Jira defect does not automatically mean the issue is closed.

The original scenario should be re-executed.

Related workflows should often be regression-tested.

If the defect involved:

pricing;
approvals;
automation;
integrations;
permissions;
or shared Salesforce logic,

there may be downstream effects.

A seemingly small change to a Salesforce Flow or validation rule can affect multiple business processes.

That is why enterprise programs need regression thinking.

The question should always be:

What else could this change have affected?

Release Readiness Should Be Evidence-Based

Eventually every project reaches the same uncomfortable question:

Are we ready to go live?

The answer should not be based on optimism.

It should be based on evidence.

I want to know:

Have critical scenarios passed?
Are Severity 1 issues closed?
What Severity 2 defects remain?
Have integrations been validated end-to-end?
Have key user personas tested their workflows?
Are approvals working?
Is downstream data accurate?
Have regression scenarios passed?
Are training materials ready?
Is support prepared?
Is there a rollback strategy?
What is the hypercare plan?
Who owns production triage?
What happens on Day 1 if something goes wrong?

A green project status slide does not protect the business.

Validated evidence does.

UAT Is Where the Senior BSA Becomes a Risk Manager

This is one of the reasons I believe the Senior Business Systems Analyst role is frequently underestimated.

At the enterprise level, a strong BSA is not simply writing requirements.

The role increasingly becomes a combination of:

Business Analyst
Process Architect
Systems Thinker
Product Partner
Facilitator
Translator
Risk Manager

During UAT, those responsibilities converge.

You have to understand enough of the technology to investigate failures.

Enough of the business to know which failures matter.

Enough of the process to identify missing scenarios.

Enough of the stakeholders to get decisions made.

Enough of Jira and delivery methodology to keep defects moving.

And enough judgment to know when the organization is genuinely ready to deploy.

That is much more than testing.

The Best UAT Finds Problems

Sometimes project teams become uncomfortable when UAT starts exposing defects.

I view it differently.

If UAT finds an important issue before production, UAT succeeded.

The expensive defect isn’t the one discovered during testing.

The expensive defect is the one discovered:

by a sales representative while negotiating a strategic deal;
by Finance during month-end close;
by Operations after an order fails;
by a customer receiving the wrong document;
by executives when a revenue forecast becomes unreliable;
or by hundreds of users on Monday morning after deployment.

UAT exists to prevent those moments.

That makes a healthy testing cycle intentionally uncomfortable.

You are trying to break the process.

You are challenging assumptions.

You are asking edge-case questions.

You are searching for conditions the original design team did not anticipate.

Because once the system reaches production, the business will find those scenarios anyway.

UAT Is the Last Controlled Environment Before Reality Takes Over

There is a point in every technology project where the controlled environment ends.

The backlog gives way to production.

Test users become actual users.

Synthetic transactions become real customers.

Approval simulations become real revenue decisions.

And defects stop being Jira tickets and start becoming business disruption.

That is why I don’t think of UAT as:

“Does the software work?”

I think of it as:

“Are we confident enough in the people, process, data, technology, integrations, controls, and operating model to put real business through this system?”

That is a much higher standard.

And for Salesforce, CPQ, Revenue Cloud, GTM systems, and broader enterprise transformation programs, it should be.

Because UAT isn’t simply the final stage before deployment.

It is the last line of defense between a project team and the business consequences of everything the project team may have missed.

UAT Is Not Just Testing: It’s the Last Line of Defense Before Business Disruption