On this page: Learn how journey simulation lets you test with simulated users, and how the simulation experience varies depending on your journey type before you publish.
You can set the journey to Simulation in addition to Draft, Test mode, and Live. In Simulation, you test with simulated users: temporary profile-like entities you add, without using persistent test profiles in Adobe Experience Platform.
Adobe Journey Optimizer offers two ways to test and validate your journey:
-
Simulation: Use the Simulation journey feature and simulated users without pre-created profiles in Adobe Experience Platform, supporting both AI-powered and manually created users.
-
Test mode: Use persistent profiles flagged as test profiles in Adobe Experience Platform, reusable across sessions. Choose this approach when you need consistent, predefined data. Learn how to create test profiles.
Simulation by journey type by-journey-type
The Simulation panel shows only the steps your journey needs. That depends on how profiles enter the journey. From these factors, Adobe Journey Optimizer surfaces different simulation experiences. Expand each type below to see how the run differs and which panels you use.
For details, see Simulate your journey.
The journey is triggered by a Read audience and the canvas has no unitary event activities. During simulation, the audience population is not triggered. Only simulated users enter the journey.
Simulated users selected for the simulation appear in the Test users section:
A segment-trigger journey that includes one or more unitary events along the path. You first trigger simulated users to enter the simulation and then trigger events for the users that wait at an event node.
Simulated users selected for the simulation and configured events will be visible respectively in the Test users and Test events sections. The Test events section will not be visible until a simulated user enters the journey.
The journey starts with a unitary event, not a read audience. A simulated user does not enter the journey until that start event is fired for them.
Simulated users selected for the simulation and configured events will be visible respectively in the Test users and Test events sections. The Test users section does not include an action to trigger a simulated user into the journey. You trigger entry from Test events.
Launch Simulation launch
Switch the journey to Simulation to test with simulated users. Step-by-step tasks are detailed in Simulate your journey.
-
From your journey, click Simulate and choose Simulation.
-
Wait for activation to complete. While the journey switches to Simulation, the controls in the panel are disabled and re-enable automatically once activation finishes.
Limitations limitations
In this release, Simulation may not support every activity, channel, or integration that Test mode or a live journey supports, and behavior may change as the capability matures. Use this article for supported workflows.
Refer to the drop-downs below to learn more about Simulation limitations.
Some nodes prevent Simulation from starting. Others run in simulation with the behavior described below. When a node must be removed or changed before you simulate, update the journey first.
| table 0-row-2 1-row-2 2-row-2 3-row-2 4-row-2 5-row-2 6-row-2 7-row-2 8-row-2 9-row-2 10-row-2 11-row-2 | |
|---|---|
| Restricted node | Notes |
| Business Events | You cannot run journeys that start with a business event in Simulation. |
| Supplemental ID (multiple re-entrance) | Simulation does not start when multiple re-entrance is enabled and the same simulated user could have several active instances at once. |
| Content Decision node | Remove or change this activity before you simulate the journey. |
| Dataset Lookup | Simulation does not support customer dataset lookups by key. Remove or change this activity before you run a simulation. |
| Optimize activity | Experiment and Targeting rule are not supported. Remove or change the node before you simulate. Other Optimize methods behave as follows: Percentage split: The Journey Agent creates one simulated user per branch, not according to branch percentages. At runtime, live evaluation picks the branch and it may differ from the generated path. You cannot mock a branch choice. To steer users, rely on branch order on the canvas. The top branch is always chosen. Time condition: Conditions apply at runtime as in a live journey. For example, a window from 8:00 to 20:00 only lets users through while simulation runs inside that window. You cannot mock execution time. Set the condition to match the current time when you test. Date condition: Conditions apply at runtime as in a live journey. For example, a date of June 8, 2026 only lets users through when simulation runs on that date. You cannot mock execution date. Set the condition to the current date when you test. Profile cap: Caps are not enforced during simulation. The Journey Agent creates one simulated user per branch. You cannot mock a branch choice. To steer users, rely on branch order on the canvas. The top branch is always chosen. |
| Timeout and error branches | The Journey Agent does not generate users for activity timeout or error branches. Users only enter those paths if a real timeout or error happens during simulation. |
| Timeout branch (event activities) | Simulated users are created, but in Manual simulation the Journey Agent does not decide who enters an event timeout branch. Control the path by sending or not sending the event. For example, to test a timeout branch, wait out the configured timeout and do not send the event. Quick simulation can send or withhold events automatically to cover timeout branches. |
| Reaction events | Reaction events run in simulation, but the action must happen in real life. For example, an email open reaction requires opening the proof message. You cannot mock reactions in the simulation UI. |
| External data sources | Calls run during simulation the same way as in a live journey. Downstream activities can use the response, but you cannot mock it. When a response value feeds an Optimize activity, the Journey Agent cannot invent that output. It only generates inputs for the call. For example, if a call takes a profile city and returns weather, the Agent sets a city on the simulated user and the live call returns the weather. |
| Custom actions | Behavior matches external data sources. Outbound calls run for real. The Journey Agent fills in inputs. Outputs come from the live response. You cannot mock responses. |
| External audience attribute enrichment | Journeys that use personalized attributes from external audience sources do not start in Simulation when this validation applies. |
The following capabilities are not supported in Simulation.
| table 0-row-2 1-row-2 2-row-2 3-row-2 4-row-2 5-row-2 6-row-2 7-row-2 8-row-2 9-row-2 10-row-2 11-row-2 12-row-2 13-row-2 | |
|---|---|
| Capability | Notes |
| Exit criteria | Exit criteria are not applied when you run Simulation. |
| Adobe Journey Optimizer decisioning inside an action, for example, email content with Adobe Journey Optimizer decisioning | Action proofs for content that uses Adobe Journey Optimizer decisioning are not generated. |
| Mock custom action response | Custom actions perform a real outbound call by default. Mocking the response so no external call runs is not supported. |
| Consent policy evaluation | Consent cannot be mocked at the simulated-user level and consent policies are not evaluated during simulation. |
| Journey capping and arbitration | Not evaluated nor enforced during simulation. |
| Frequency capping (by channel or communication type) | Not evaluated nor enforced during simulation. |
| Opt-out management, suppression, and allow lists | Not evaluated nor applied during simulation. |
| Dynamic subdomain and dynamic attributes in channel configurations | Not supported. |
| Send Time Optimization (STO) | Not evaluated nor applied during simulation. |
| Sandbox tooling (copy simulated users across sandboxes) | Not supported. |
| Wave sending in journeys | Not supported. |
| Quiet hours | Not evaluated nor applied during simulation. |
| Privacy service | Simulated users are not GDPR-compliant persistent profiles. Do not include real customer data in simulated users. |
These guardrails apply to Simulation. Numeric caps are enforced in the journey interface and at runtime. Limits may change in a later release. If you run near a ceiling, verify behavior in your sandbox.
| table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3 5-row-3 6-row-3 | ||
|---|---|---|
| Guardrail | Limit | Notes |
| Maximum simulated users that can be selected and triggered in one batch (batch journeys, event-triggered flows, and audience-qualification flows) | 20 | Counted for each Send all or Trigger selected events, not a cumulative cap for the whole journey. |
| Maximum simulated users per generation request | 50 | Maximum simulated users the Journey Agent generates in one request through Quick simulation or Generate with AI in Manual simulation. If the journey has more than 50 paths, the Journey Agent randomly selects paths to produce those 50 simulated users. |
| Maximum unique simulated users tested in a single simulation run | 100 | Reaching 100 unique users in one run blocks Select simulated users for new simulated users. If you are at 90, you can add at most 10 more before the same block. |
| Maximum journeys that can run in Simulation at the same time in one sandbox | 20 | Cap is shared by every Simulation journey in that sandbox at once. |
| Maximum active simulated users in one sandbox | 2,000 | Maximum simulated users that can exist in the sandbox at one time. Adobe may adjust this limit based on customer feedback. |
| Event Pre-fill (Browser Only) | — | You can pre-fill event payload fields only in the browser-based simulation UI. Pre-filled values stay in that browser and are not synced to other browsers, devices, or sessions, so you may see different pre-fill data in each place you test. |