# Browser simulations

> Exercise your application through a browser with repeatable participant roles and tasks.

Browser simulations use automated participants to exercise a journey in your application. A saved simulation defines the scenario and each participant’s role and task. Launch a run to execute that definition and review what happened.

Owners and admins create simulations and sign-in secrets; members can run existing simulations and manage their executions. The simulation service must be able to reach your test application, including any private environment it uses. Confirm that access with the team managing the service, and use test accounts and an appropriate test environment.

## Create your first browser simulation

Open **Simulations → New simulation**. In **Basics**, give the test a recognizable name and set **Maximum duration (minutes)** to bound execution.

In **Scenario**, describe the situation shared by the participants. **Expected result** describes the outcome you will assess after the run. Participants do not receive it; give them the information needed to act in their own instructions.

For example, a booking scenario might ask a customer to reschedule an existing appointment. Its expected result could require both a visible confirmation and the changed appointment in your application’s records.

Under **Participants**, configure the customer:

* **Persona** describes the role and relevant knowledge, such as a returning customer with an existing booking.
* **Instructions** provides the application URL, task, constraints, and when to finish. Specify the requested change without revealing an answer the participant should discover itself.
* **Browser** enables browser interaction. Enable other capabilities only when the scenario needs them.

Choose **Save simulation**, then **Run… → Start run** on the saved definition. Open the run from **Runs** to follow its progress and inspect its evidence. See [Runs and results](/docs/platform/simulations/runs-and-results.md) for assessing the outcome and resolving waiting states.

To inspect your application’s agent, model and tool activity alongside the simulated interaction, configure [application evidence](/docs/platform/simulations/runs-and-results.md#application-evidence).

Editing the definition affects subsequent launches. It does not change participants, instructions, or the deadline of a run already launched.

## Use sign-in secrets

Keep passwords and other credentials out of Scenario, Persona, and Instructions. Owners and admins add them under **Settings → Project settings → Simulations → Add secret**; **Secrets** in Simulations also opens secret management.

Give each secret a name, value, and **Allowed origins**. Use HTTPS origins without paths, such as `https://app.example.com`; separate multiple origins with spaces. In the definition, use **Choose secrets** to select the secrets each participant may use.

Use a secret’s action menu to **Rotate…** its value while retaining its reference, or **Revoke…** it to prevent future authentication. Revocation cannot be undone; add a new secret and update the definition if access is needed again.

Authentication can use only enabled, selected secrets allowed for the requesting origin. If a run pauses with **Needs sign-in**, [resolve its authentication request](/docs/platform/simulations/runs-and-results.md#resolve-an-authentication-request). Adding a secret to the definition after launch does not add it to that run’s snapshot.

For a journey that crosses from a browser to a phone call, configure the relevant participant’s [voice capabilities and resources](/docs/platform/simulations/voice-simulations.md). Add a [schedule](/docs/platform/simulations/schedules.md) after validating the scenario manually.