Skip to main content

​
Description

Jump to Flow/Step moves the call to a flow and step you choose while the call is running. Normal routing decides where to go next when you build the script. This tool decides where to go next from variables, so the target can change from call to call. Good fits:
  • Send the caller to a different flow depending on a value looked up mid-call — a product, a state, a policy type
  • Route from a table of destinations held in a custom variable or fetched from a webhook
  • Reuse one entry flow for many outcomes, without a long chain of conditions
When the flow you jumped to ends, the call comes back to the step after the jump, so the rest of the flow you started in still runs.

​
Manual Inputs

​
Flow

The ID of the flow to jump to. This is normally a {{...}} variable that was filled earlier in the call, for example {{custom.target_flow_id}}. The flow must already be part of the script. You cannot jump into the hidden implementation flow behind a composite tool.

​
Step

The ID of the step within that flow — again, usually a variable such as {{custom.target_step_id}}. Step IDs are numbered per flow. Step 3 in one flow is a different step from step 3 in another, so always set the pair together.

​
Manual Outputs

​
Conditions

​
Success (true)

The flow and step were found and the call jumped to them. The rest of the target flow then runs, and when it finishes the call returns to the step after this one.

​
Failure (false)

The jump did not happen, or did not complete. Usual causes:
  • The flow ID or the step ID could not be found — often an empty variable, or a value from a different script
  • The target is not allowed, such as a composite tool’s internal flow
  • The flow was entered but did not finish successfully
Route the failure path to a sensible fallback — a generic flow, or a voice step that asks the caller a question instead.

​
Variables this tool writes

Variables this tool writes: none. Jump to Flow/Step has no variable namespace of its own and writes nothing to any {{...}} variable. Its only signal is the boolean result you route on. Any values you want to carry into the target flow must already be in variables before the jump — the tool moves the call, it does not pass arguments. Values written inside the target flow are still there when the call returns, because variables live for the whole call. The two inputs are the variables that matter here, and you set them yourself: Name your own variables however you like — these are just the usual pattern. For the full list of namespaces and fields, see Variables.

​
Example Usage

Route to a product-specific flow chosen by a lookup:

​
Common Issues

  • Always returns false — check the variables actually hold values at that point in the call. An empty variable is the most common cause.
  • The call jumps somewhere unexpected — the step ID belongs to a different flow. Set the flow and step together, from the same source.
  • The call does not come back — it does come back to the step after the jump, but only once the target flow ends. A target flow that transfers the caller or ends the call never returns.
  • Jumping into a composite tool fails — composite tools run their own internal flow and cannot be jumped into. Use the composite as a tool step instead.

​
Best Practices

  1. Fill both variables from one source so the flow and step always match.
  2. Check before you jump — a Code Step that confirms both values are non-empty saves a wasted step.
  3. Always route the failure path, even if it only apologises and continues.
  4. Keep target flows self-contained so they end cleanly and hand the call back.
  5. Prefer normal conditions for fixed choices — use this tool when the destination is genuinely decided at run time.

​
Next Steps

  • Tool Steps — Learn how to configure tool steps
  • Flows — How flows and sub-flows fit together
  • Variables — See all available variables