4.1 Validation, Simulation, Test Mode, and Dry Run Execution

4.1 Validation, Simulation, Test Mode, and Dry Run

A journey can be structurally valid and still be wrong. Journey Optimizer therefore provides validation plus three execution methods with different people and side effects. Match each method to the risk being tested.

Validation

Validation checks whether required configuration is complete enough to run or publish. It can identify missing activity settings, invalid expressions, unavailable dependencies, unconfigured branches, and other structural errors.

Validation cannot prove that:

• the selected audience is the intended population;
• a condition implements the business rule correctly;
• content looks good in every client;
• a personalization value exists for real recipients;
• a custom endpoint behaves safely at production volume;
• consent and governance rules match the campaign's intent.

Resolve every blocking error, then continue with execution testing.

Simulation

Journey Simulation uses temporary simulated users created manually or generated for the test. It is designed for fast iteration while authoring, without creating an AEP test profile and waiting for that profile to propagate.

Use Simulation to explore paths, supply representative attributes, inspect expressions, and verify expected outcomes quickly. Simulated users can define execution addresses for supported message testing. Because these are temporary inputs, Simulation does not establish that a real profile, audience, identity, or ingestion pipeline is configured correctly.

A useful simulation set includes a normal profile, each major branch, missing optional data, an ineligible profile, and boundary values.

Test mode

Test mode runs a draft journey with persistent Adobe Experience Platform test profiles. A test profile is deliberately marked for testing and contains the identities and channel data needed by the path. A session supports up to 100 test profiles.

Test mode can send actual messages to the test profiles' execution addresses, so it is not harmless preview-only rendering. Use controlled inboxes, devices, phone numbers, endpoints, and provider configurations. By default, waits are reduced to ten seconds to make path testing practical, but confirm the test settings when timing itself is the subject.

For event-driven testing, trigger events through the test interface and inspect the displayed event identifiers and results. Test mode helps verify identity resolution, profile fields, event context, channel content, and downstream branch behavior using persistent test records.

Dry run

Dry run evaluates the journey against real production data without contacting customers and without applying profile updates. Communications and custom-action side effects are bypassed. It is available for an eligible error-free draft and is intended to show how production profiles would flow.

Use dry run to measure entry, path distribution, qualification, caps, and discards at realistic scale. It is particularly valuable before launching a large audience journey. A dry run does not prove deliverability or external endpoint behavior because those actions are not actually executed.

Comparison

Release sequence

1. Validate until no blocking errors remain.
2. Simulate normal, boundary, null, and ineligible cases.
3. Use test profiles to verify identity, event context, channel configuration, and rendered content.
4. Conduct channel-specific proofs across devices and clients.
5. Run dry run against production data and inspect volume, paths, errors, and discards.
6. Obtain required content, privacy, and operational approvals.
7. Publish and monitor early execution.

A method can be repeated after changes. If a later edit affects logic, content, entry, or dependencies, repeat the relevant tests instead of relying on an old result.

Common traps

• Calling Simulation “Test mode” and assuming it verifies persistent Profile data.
• Assuming Test mode cannot send actual messages.
• Using a production customer's address as a test destination.
• Treating dry run as a deliverability test.
• Declaring success because validation passed.
• Expecting a detached or terminal branch to be a blocking error merely because no activity follows; verify whether the path intentionally ends.