> For the complete documentation index, see [llms.txt](https://learning.contextqa.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://learning.contextqa.com/business-use-cases/salesforce-and-enterprise-workflows.md).

# Salesforce and Enterprise Workflows

## Quick answer

Protect Salesforce lead, opportunity, CPQ, revenue, and service workflows with reusable sessions, UI/API validation, and evidence. Use this page to connect the business problem to a supported ContextQA workflow, its expected value, and its operating considerations.

## What this page covers

{% hint style="info" %}
**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.
{% endhint %}

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](/files/cE30BKrMYzBo9Vaer47A)

## 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-testing/salesforce-testing.md)
* [Salesforce test generation and execution](/salesforce-testing/test-generation-and-execution.md)
* [Test data management](/web-testing/test-data-management.md)
* [API testing overview](/api-testing/api-testing.md)
* [Self-healing](/web-testing/self-healing.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://learning.contextqa.com/business-use-cases/salesforce-and-enterprise-workflows.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.