> For the complete documentation index, see [llms.txt](https://docs.flxbl.io/flxbl/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flxbl.io/flxbl/codev/service-virtualization/service-virtualization.md).

# Service Virtualization (Limited Preview)

{% hint style="warning" %}
**This feature is in limited preview** — it is available to selected customers only, and behaviour and commands may change based on feedback. Reach out to the flxbl team if you would like early access.
{% endhint %}

Most Salesforce projects call external systems — Flows through HTTP callout actions, Apex through Named Credentials, External Services wrapping REST APIs. Those paths are hard to test in a review environment: the sandbox often has no network path to the vendor's test system, the test system has no data for the scenario under review, or it charges per call. In practice, clickthrough testing tends to skip everything behind a Named Credential.

Service virtualization replaces a project's declared external integrations with mocks for the duration of a session. A session is started with a pull request comment: codev points the review environment's Named Credentials at a mock endpoint it hosts, and serves responses from the rules and OpenAPI specs committed in the repository. Ending the session restores the credentials to their original endpoints.

```
sfp mock /all          ← comment on the pull request
```

```
Mock Session Active

| Service            | Named Credential         | Stubs |
|--------------------|--------------------------|-------|
| OrderStatusApi     | Order_Status_Service     | 2     |
| ShippingTrackerApi | Shipping_Tracker_Service | 3     |

Named Credentials in the review environment now point at the mock data plane.
```

### How it works

A mock session has three layers:

1. **The baseline lives in git.** Each package declares its external services in `mocks/mocks.yaml`, optionally with a rules file describing the responses, and the repository can carry scenario playbooks for multi-service test cases. The baseline is whatever those files say *at the pull request's branch* — mocks are versioned and reviewed like any other change.
2. **Session edits live in codev.** While a session is active, responses can be changed without touching the repository — by arming a scenario or by replacing a service's rules through the API. Edits are scoped to the session and survive re-activation.
3. **The mock engine serves the result.** codev renders baseline plus edits into a per-session mock instance and rewrites the review environment's Named Credentials to point at it. Every request is journaled, including requests that no mock matched — so a missing mock is visible, not silent.

The switch happens **inside the review environment, at session start** — package source is never modified, and credentials never gain mock URLs in version control. Ending the session (or closing the pull request) restores the original endpoints.

### Capabilities

* **Callouts in review environments** — Flows and Apex that depend on external systems can be executed in environments with no network path to those systems.
* **Deterministic responses** — repeated runs of the same clickthrough receive the same responses.
* **Failure injection** — error statuses, latency (`delayMs`), and responses that change across repeated calls.
* **Scenario switching** — committed playbooks (for example `order-happy-path`, `order-delayed`) are switched with a comment: `sfp mock scenario order-delayed`. Every service the scenario covers changes together.
* **Request journal** — every callout the org made during the session, flagged when no mock matched it.
* **One surface for people and agents** — every session operation (activation, rule edits, journal, scenarios) is available over an HTTP API, and the common ones double as pull request comments; developers, testers, test automation and AI agents work against the same session.

### What does not change

* **Sessions are opt-in.** Orgs without an active session behave exactly as before; packages that declare no mocks are untouched.
* **Package source is never modified.** Discovery writes `mocks/mocks.yaml` next to your source for you to review and commit; the credential switch is an org-side operation that is undone at session end.
* **Validation and deployment are unaffected.** Mock declarations are inert metadata to every other sfp command.

### Requirements

* **Review environments configured** — sessions attach to the review environment assigned to a pull request.
* The Named Credentials being virtualized must **exist in the review environment**. They do not need to exist in package source; org-only credentials work.
* Mocking covers **HTTP callouts made through Named Credentials** (including External Services). Callouts that hard-code URLs without a Named Credential cannot be switched.

### Where to go next

* [Declaring mocks](/flxbl/codev/service-virtualization/declaring-mocks.md) — discovering integrations and writing `mocks.yaml` and rules files
* [Mock sessions on pull requests](/flxbl/codev/service-virtualization/mock-sessions.md) — starting, controlling and ending a session with PR comments
* [Scenario playbooks](/flxbl/codev/service-virtualization/scenario-playbooks.md) — capturing, editing and replaying multi-service test cases


---

# 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://docs.flxbl.io/flxbl/codev/service-virtualization/service-virtualization.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.