Salesforce and Enterprise Workflows

Protect Salesforce lead, opportunity, CPQ, revenue, and service workflows with reusable sessions, UI/API validation, and evidence.

Business problem: Salesforce processes cross dynamic Lightning pages, custom objects, permissions, APIs, approvals, documents, and downstream systems. A UI-only happy path does not provide enough release confidence.

Build Salesforce coverage around business lifecycles rather than individual screens. ContextQA can reuse an authenticated Salesforce session, execute natural-language Lightning steps, combine UI and API verification, drive record variations from test data, and retain evidence for each run.

ContextQA Test Suites showing Salesforce UI, API, CPQ, agent lifecycle, and revenue workflow coverage

High-value process maps

Process	Representative coverage	Business risk addressed
Lead to opportunity	Lead creation, qualification, conversion, owner assignment, stage and history checks	Lost pipeline, routing errors, inaccurate forecasting
Opportunity to quote	Products, price books, discounts, approvals, quote generation, synchronization	Incorrect pricing, margin leakage, approval bypass
Quote to contract or order	Acceptance, document generation, downstream handoff, status reconciliation	Revenue delay, mismatched commercial records
Service and case management	Case intake, priority, assignment, status, escalation, communication	SLA breach and inconsistent customer service
Account and contact lifecycle	Create, update, duplicate handling, permissions, relationship integrity	Bad customer data and access-control errors
Agent or guided workflow	Prompt/action sequence, tool or API result, audit history, fallback	Incorrect autonomous action or missing human escalation

Reuse the authenticated session

Create a Salesforce session-login test and select it as a prerequisite for dependent cases. Keep credentials and authenticator material in protected parameters. This shortens authoring, centralizes authentication maintenance, and allows the business case to begin from a known logged-in state.

Verify outcomes, not clicks

For a stage-change test, assert the new stage, its history entry, relevant calculated fields, and any required downstream action. Use AI verification for dynamic page content where appropriate, but make the expected business state explicit.

Add API verification when Salesforce UI state alone is insufficient—for example, confirming an OAuth-backed update or downstream CPQ object. Use read-only queries or dedicated test records where possible.

Design stable enterprise tests

• Reference fields by labels, roles, and business context rather than generated DOM identifiers.
• Parameterize record types, users, regions, currencies, products, and approval thresholds.
• Use unique synthetic names or run identifiers to prevent collisions in parallel execution.
• Keep cleanup explicit so repeat runs do not accumulate records or alter shared baselines.
• Separate environment configuration for each sandbox.
• Review self-healed steps after Salesforce seasonal updates or page-layout changes.

Example: discount approval

1. Reuse the authenticated sales-user prerequisite.
2. Create or open an opportunity with parameterized products.
3. Generate a quote and apply a discount at the approval boundary.
4. Verify the quote cannot bypass the required approval.
5. Complete the manager approval with a permitted test identity.
6. Verify quote status, totals, history, and the associated opportunity.
7. Confirm any downstream API or generated document reflects the approved amount.

Add cases immediately below and above the threshold, a rejected approval, an unauthorized user, a multi-currency variation, and a dependency failure.

Success measures

• Revenue and service lifecycle steps covered across UI and API
• Reuse of session and record-setup prerequisites
• Sandbox-specific failures and test-data collisions
• Salesforce release changes absorbed without unintended test behavior
• Time to identify whether a failure belongs to configuration, permissions, data, integration, or product logic
• Critical record changes supported by execution evidence and history

Related documentation

• Salesforce testing overview
• Salesforce test generation and execution
• Test data management
• API testing overview
• Self-healing