Jump To
The Jump To node teleports the conversation from the current flow to another flow — or to a specific point within any flow, including the current one. When it executes, the conversation vanishes from where it was and reappears at the destination. The source flow is done; execution continues from wherever you landed.
This makes Jump To the primary tool for modularizing complex processes. A twelve-step onboarding doesn't fit on one canvas. Split it into separate flows, each handling one logical phase, and chain them together with Jump To nodes. Each piece becomes manageable on its own, testable in isolation, and the connection points are explicit.
When to Use It
Breaking apart large processes. When a flow grows too large to reason about, split it. Put each logical phase in its own flow and connect them with Jump To nodes. "Onboarding Step 1" ends with a Jump To that targets "Onboarding Step 2", which in turn jumps to "Onboarding Step 3", and so on. Each flow handles one concern, fits on one screen, and can be tested independently.
Converging error paths to shared handling. A "Failure and Support" flow handles errors and escalation. Many different flows need access to it: validation failures, document rejections, retry limits exceeded. Instead of duplicating error handling everywhere, each flow jumps to the shared destination when something goes wrong. Change the error handling once, and every path that uses it benefits.
Routing returning customers. A customer comes back after three days. Check where they left off and jump them directly to the right phase. Were they on step five? Jump to step five. New customer with no progress? Jump to account creation. The routing logic lives in one place, and Jump To handles the actual transfer.
Retrying without starting over. SRI validation failed, but the customer doesn't need to redo the entire flow. Show a "Let's try again" message and jump back to the validation node — same flow, but landing past the introduction. They skip the parts they've already completed.
How It Works
Configure the target flow and, optionally, a specific node within it. When the Jump To executes, the conversation's position updates: different flow, different node, potentially different flow version. Variables persist — they live on the conversation, not the flow, so anything you've stored remains accessible after the jump.
If you leave the target node empty, the conversation lands on the first node after the target flow's Start node. Start itself is skipped; you arrive at whatever meaningful node begins that flow.
Landing on a Specific Node
When you specify a target node, the conversation lands exactly there, skipping everything before it in the target flow. This is how retry patterns work: jump back to the validation step without repeating the greeting and setup that preceded it.
The target node must exist in the target flow. If it doesn't — perhaps it was deleted during editing — the system falls back to the flow's starting point.
On the Canvas
Jump To has an input handle but no output handle. Nothing can follow it in the source flow because execution has moved elsewhere. It's always a terminal node within its branch. The conversation continues in the target flow, not here.
This is different from End, which terminates the conversation entirely. Jump To transfers control; End stops everything.
Version Pinning
If the target flow is under active development, you can pin the jump to a specific version. This prevents work-in-progress changes from affecting conversations mid-flight. Specify the version number and status (Active, Draft, or Archived), and the system uses that exact version regardless of what's been published since.
Immediate vs Deferred Evaluation
The "evaluate node" setting controls what happens after landing:
When enabled (the default), the target node processes immediately. The conversation continues without pause — whatever that node does happens right away, and if it connects to further nodes, those execute too.
When disabled, the conversation state updates but processing stops. The system waits for the next message from the customer before the target node executes. This is useful when you want to "park" the conversation at a specific point until the customer responds.
Things to Know
Same-flow jumps are valid. The target flow can be the flow you're already in. Combined with a specific target node, this creates retry loops that skip already-completed steps.
Missing target flows cause errors. If the target flow doesn't exist — wrong ID, deleted flow — the jump fails. Ensure your targets remain valid when reorganizing flows.
Goal nodes typically precede jumps. Track that a phase completed before transferring to the next phase. This keeps your analytics meaningful across multi-flow processes.