Inspect a campaign journey simulation

The Journey canvas can project a draft graph before you activate a campaign. Use the simulation to answer a narrow question: how does an estimated cohort move through this graph, and where does it stop? The result is project-only. It does not enroll a contact, queue a message, or call a provider. The current canvas simulator is a cohort projection, not a live contact replay: it does not read a contact record or create a per-contact execution trace. The Inspector terminology below refers to the projection results shown beside the canvas: inspect each nodeResults row and its exact nodeId. This guide shows how to use the branch assumptions to test a contact-shaped path without changing tenant data. This guide assumes you have a journey draft open in Outbound → Campaigns → Journey. For the graph itself, see Build, simulate, and launch a campaign journey. For a journey that is already being refused at launch, see Troubleshooting: campaign and journey enrollment errors.

1. What the simulator executes

Select Simulate in the journey toolbar. The simulator runs the same in-memory nodes and edges that the canvas is editing. It does not reload a different saved version, enroll a real contact, or execute live actions. The projection evaluates graph structure and contact inputs only:

A trigger provides the entry point for the estimated cohort.
A wait passes the projected volume to the next node; the current result does not advance or return a per-contact clock.
A condition projects yes and no volumes from the configured pass rate.
An A/B split projects each branch from its configured weights.
A send node contributes a projected send count; it does not send.
An end or exit node contributes to the projected terminal outcome.

Save the graph before you use the result as a review artifact. You can simulate an unsaved draft, but the trace describes the current canvas state, not the last saved definition used by a running campaign.

2. Pick a sample contact

Start with an entry cohort size that represents the population you want to inspect. In the simulation panel, set Entry cohort size and review the graph fields your conditions read. For a contact-shaped test, write down the sample contact’s relevant attributes and translate them into a branch pass-rate assumption; the current cohort simulator does not fetch contacts, events, or tenant attributes. Use assumptions when you need to force a branch without changing tenant data. A global Branch pass rate (%) controls the default share taking the yes path, while a per-node override controls a named condition. These values apply only to the projection. For example, for a condition that reads plan, prepare two contact-shaped cases: an eligible contact (plan = pro) and an ineligible contact (plan = free).

Sample contact shape: ct_2048
Attributes used for review:
  plan = pro
  country = GB
  journey_engaged = false
Entry event:
  contact.created
Projection assumptions:
  conditionPassRate = 1.0 for the eligible case

To exercise both sides of a condition, run the same graph twice:

Run the eligible case with a 100% pass rate and confirm the yes handle.
Run the ineligible case with a 0% pass rate and confirm the no handle.
Remove the temporary assumption before you save or activate. Assumptions never become contact updates.

Supply every value a branch needs. A missing attribute is not the same as an empty string, false, or zero. If a condition has no usable value, the Inspector marks the decision unresolved rather than silently guessing a branch. For date-based waits, use a contact with the date field populated and confirm the timezone shown by the project. If the journey enters from a segment, choose a contact that is actually in that segment or use the segment-entry context offered by the simulator.

3. Read each projected step

After the run, read the projection results in node order. The current result includes one row per graph node with its exact nodeId, label, projected arrival volume, and whether that node is reachable. Select the matching node on the canvas to inspect its configuration. Read branch volumes and warnings alongside the rows; the result does not include an execution-time contact timestamp or a per-contact resolved attribute value.

Step	Read it as
Trigger	The row is the entry node. Its `arrivedVolume` is the projected cohort entering the graph; it is not a contact-admission verdict.
Wait	The row passes its `arrivedVolume` onward. A 1-day wait does not sleep for a day, create a scheduler job, or add a timestamp to the current result.
Condition	Compare the projected arrivals on the `yes` and `no` edges using the configured pass rate. The result does not show a contact’s resolved field value.
A/B split	Compare each downstream arrival volume with the configured weight. The split is a projection of assignment, not an experiment assignment stored for a contact.
Send	The row’s arrival volume contributes to the channel’s projected send count. No message is created and no delivery result exists.
Goal or exit	The node’s arrivals contribute to `completedVolume`, `exitedVolume`, or `unresolvedVolume`, depending on the graph path.

For a 1,000-contact entry cohort, a 1-day wait still contributes 1,000 projected arrivals to the next node. The wait changes live execution timing, but the current graph projection does not calculate timestamps, contact attrition, or delivery time.

A/B split math

For a split with variants weighted 70% and 30%, the simulator normalizes the weights to 0.70 and 0.30. For an entry cohort of 1,000 contacts, the projection is:

Variant A: 1,000 × 0.70 = 700 projected contacts
Variant B: 1,000 × 0.30 = 300 projected contacts

A single-contact trace shows one selected branch; it does not claim that the contact will be permanently assigned in a live run. If the configured weights do not sum to 100%, fix the split before relying on the trace.

4. Map branch handles to outcomes

The label on an edge is the contract between a decision node and its next step. Read the sourceHandle on the edge and compare it with the result shown in the Inspector:

Node	Handle	Outcome
Condition or Score Check	`yes`	The comparison evaluated true.
Condition or Score Check	`no`	The comparison evaluated false.
Wait for Event	`event`	The named event arrived in the projected scenario.
Wait for Event	`timeout`	The event did not arrive before the configured timeout.
A/B Split	Configured variant handle	The weighted assignment selected that variant.

Do not infer a branch from its position on the canvas. A lower edge is not automatically no, and a right-hand edge is not automatically a timeout. Select the edge or node and verify its handle label. If a handle has no outgoing edge, the Inspector can report a branch as unresolved even when the other branch reaches an exit.

5. Fix common simulator findings

The Inspector distinguishes a projected graph problem from a launch refusal. When it names a node, copy the exact node id into your review notes; ids are more reliable than node labels, which can be duplicated.

Finding	What it means	Smallest graph change
Unreachable node (`node_id: n_goal`)	No admitted path from the trigger reaches `n_goal`.	Connect the missing incoming edge to the intended predecessor, or delete `n_goal` if it is not part of the journey. Do not add another node first.
Cycle (`n_condition → n_send → n_condition`)	A non-wait path returns to an earlier node and cannot produce a finite projection.	Remove the one edge that closes the loop, then connect that handle to the intended exit. A wait-and-re-evaluate pattern is distinct from an ordinary graph cycle; review the validator message before changing it.
Missing exit criteria (`node_id: n_goal`)	A path reaches the goal or a branch end without a configured goal or terminal outcome that finishes the contact.	Configure the intended goal or add the smallest terminal End Journey edge from the open handle.
High send density (`node_id: n_send_2`)	The projection places too many sends close together for the configured path.	Add an appropriate wait between adjacent sends, or remove the redundant send. Keep the change on the path named by the Inspector.

Run the simulation again after each graph change. A clean trace should show an admitted trigger, a finite sequence of node ids, explicit branch results, and a goal or terminal outcome.

Projection finding or launch validation failure?

A projection finding is attached to the sample run: it names a node or handle in the trace, such as n_goal being unreachable or no having no edge. Fix the graph, then run the projection again. A launch validation failure is a refusal for the saved campaign or resolved audience, such as JOURNEY_DEFINITION_INVALID, JOURNEY_TRIGGER_MISSING, JOURNEY_TRIGGER_DISCONNECTED, AUDIENCE_TOO_LARGE, or a channel/send-gate refusal. It can happen even when one sample trace looks healthy. Copy the error code and request id and follow Troubleshooting: campaign and journey enrollment errors; do not try to fix a launch refusal by changing only the sample contact.

6. Walkthrough: segment entry, one-day wait, send, and goal

Use this small graph to reproduce the same example described in Campaign journeys: a segment admits the contact, the journey waits one day, sends a message, and checks a goal condition.

Before the fix

The draft contains these nodes and edges:

n_segment  (segment entry: VIP trialists)
  └─→ n_wait_1d  (wait: 1 day)
       └─→ n_send_welcome  (send: SMS)
            └─→ n_goal  (condition: trial_started)
                 └─yes→ n_end_success

The no handle from n_goal is not connected. Run the simulator with this sample context:

Contact: ct_2048
segment: VIP trialists
trial_started: false
Projected start: 2026-10-11T09:00:00Z

The projection results show the reachable node rows before they report the open path:

nodeId           arrivedVolume   reachable   projected result
n_segment        1,000           true        entry
n_wait_1d        1,000           true        wait passes volume onward
n_send_welcome   1,000           true        channel=sms, projected send
n_goal           500             true        yes=500, no=500
warning          —               —           missing no path from n_goal

This is not a failed SMS or a live enrollment. It is a graph projection that found a branch with nowhere to go. The exact node id is n_goal, and the missing handle is no. The 500/500 split uses the default 50% pass rate; set a per-node override when your sample-shaped case needs a different split.

After the fix

Make the smallest change: connect the no handle to an explicit end node.

n_segment  ─→ n_wait_1d ─→ n_send_welcome ─→ n_goal
                                             ├─yes→ n_end_success
                                             └─no → n_end_not_ready

Run the same projection again. The node-id result is now finite:

nodeId           arrivedVolume   reachable   projected result
n_segment        1,000           true        entry
n_wait_1d        1,000           true        wait passes volume onward
n_send_welcome   1,000           true        channel=sms, projected send
n_goal           500             true        yes=500, no=500
n_end_success    500             true        completed
n_end_not_ready  500             true        completed

Run a second projection with a 100% pass-rate assumption for n_goal. The first three rows remain, the yes volume becomes 1,000, and n_end_success receives the full projected volume. Comparing the two projections verifies that both branch handles are wired without changing tenant data or sending either message.

7. Know when simulation is not enough

A successful projection means the graph can produce a path for the supplied sample. It does not authorize a live campaign. The launch validator still checks the saved journey and the tenant’s launch conditions, including:

Channel eligibility: the configured channel, sender, template, recipient address, and tenant channel setup must be eligible for the audience.
Audience size: the resolved audience must fit the tenant’s allowed recipient count. A one-contact simulation does not prove that the full audience will pass this check.
Per-tenant send gates: tenant-owned send controls such as quiet hours, frequency caps, suppression, consent, and configured country or channel controls still apply at launch and at send time.

If activation or enrollment returns a graph or launch error, copy the code and request id from the response and follow Troubleshooting: campaign and journey enrollment errors. Do not treat a clean contact trace as a bypass for those checks.

8. Simulation limits

The canvas simulation is intentionally a projection. It does not model:

Contact attrition during waits. A contact remains in the trace across a one-day wait; the projection does not estimate who will leave, unsubscribe, or become unreachable during that period.
Event timing noise. A projected event or timeout follows the scenario you supplied. It does not reproduce ingestion delay, clock skew, retries, or other timing variation.
Per-channel delivery outcomes. A projected send is not a delivered, opened, clicked, failed, or replied message. Read those outcomes from the live campaign analytics after activation.

Use the simulator to inspect graph intent and branch coverage. Use launch validation for readiness, and use live journey analytics for what happened to enrolled contacts.

Getting Started

Channels

Channels (Voice)

AI Agents

Campaigns

Flows

Numbers & Verify

Concepts

Features

Billing

Webhooks

Security & SSO

Compliance

Legal

Brand & press

Changelog

Inspect a campaign journey simulation step by step

Inspect a campaign journey simulation

1. What the simulator executes

2. Pick a sample contact

3. Read each projected step

A/B split math

4. Map branch handles to outcomes

5. Fix common simulator findings

Projection finding or launch validation failure?

6. Walkthrough: segment entry, one-day wait, send, and goal

Before the fix

After the fix

7. Know when simulation is not enough

8. Simulation limits

See also

​Inspect a campaign journey simulation

​1. What the simulator executes

​2. Pick a sample contact

​3. Read each projected step

​A/B split math

​4. Map branch handles to outcomes

​5. Fix common simulator findings

​Projection finding or launch validation failure?

​6. Walkthrough: segment entry, one-day wait, send, and goal

​Before the fix

​After the fix

​7. Know when simulation is not enough

​8. Simulation limits

​See also

Inspect a campaign journey simulation

1. What the simulator executes

2. Pick a sample contact

3. Read each projected step

A/B split math

4. Map branch handles to outcomes

5. Fix common simulator findings

Projection finding or launch validation failure?

6. Walkthrough: segment entry, one-day wait, send, and goal

Before the fix

After the fix

7. Know when simulation is not enough

8. Simulation limits

See also