Note: This feature is available in Preview for select customers.
Validate a Journey in the Simulator sandbox and fix configuration issues before the Journey reaches real contacts.
In this article:
- Prerequisites
- Understanding the Simulator
- Running a Simulation
- What the Simulation Validates
- Fixing Validation Issues
- Comparing the Simulator and the Monitor
- Additional Resources
Prerequisites
The following requirements apply:
- Licenses: Talkdesk Voyager enabled on the account.
- Permissions: Permission to create Journeys.
- Journey: A Journey with a trigger node and the steps and routing to validate.
Understanding the Simulator
The Simulator is a sandbox environment where a Journey is validated before it goes live. The Journey runs against test participants in an isolated environment that does not contact real customers. The Simulator exercises the trigger, steps, and routing of the Journey using test data, so configuration problems are caught early instead of after publishing.
Note: A Journey should pass validation in the Simulator before it is published to real contacts.
Running a Simulation
- Open the Journey on the canvas and finish building the flow, trigger node, plus the steps and routing to validate.
- Open the Simulator.
- Choose one or more test participants (people or sample records that stand in for real contacts).
- Start the simulation.
- Watch the simulation progress node by node and review the outcome that each step produces.
The Simulator runs the Journey against the test participants using their sample data and follows the same trigger and step logic as a live run.
Note: The Simulator always runs against the current draft of the Journey.
What the Simulation Validates
As the simulation runs, the Simulator checks the Journey for problems that would break or misroute a live run, including the following:
- Unconfigured or incomplete nodes: A step missing required configuration, such as a message with no content or a trigger node with no start type.
- Broken references: A variable chip or field mapping that points to information the Journey does not have at that step.
- Routing problems: A branch or outcome path that leads nowhere, or a condition that can never be met.
- Audience and data gaps: A Journey that expects audience fields or event data that are not mapped or available to the step that uses them.
- Template and personalization issues: Message content that references a variable with no value for the test participant.
The Simulator surfaces each issue where it occurs in the flow, so the node that needs attention is easy to identify.
Fixing Validation Issues
- Open the flagged node in the Simulator to see the specific problem and the step it affects.
- Fix the configuration on the canvas, such as completing the missing field, correcting the variable chip, or remapping the audience field.
- Re-run the simulation with the same test participants to confirm that the issue is resolved.
- Repeat until the simulation completes without validation issues.
Note: Because the Simulator runs in a sandbox, fixing and re-running a simulation does not affect any real contacts or any Journey that is already published.
Tip: Use a small, representative set of test participants that covers the key branches. For example, one per expected outcome path. This way, the simulation exercises the routes that real contacts will take.
Comparing the Simulator and the Monitor
| Simulator | Monitor | |
|---|---|---|
| When | Before publishing, during building | After launch, on live runs |
| Runs against | Test participants in a sandbox | Real contacts in production |
| Purpose | Validate the flow and catch configuration errors | Observe live progress and operate runs |
| Affects real contacts | No | Yes |
The Simulator is the pre-launch safety check. The Monitor is where Journeys are watched once they are live and where runs that need attention are handled. For instructions, see Talkdesk Voyager: Monitoring and Reporting in this article.
Note: After publishing, live runs are version-pinned. Each run stays tied to the Journey and step versions it started with, so later edits do not silently change work already in progress. For more information on versions and cloning, see Talkdesk Voyager: Building and Publishing.