Jump To

Getting here

Automate → Workflows, open a workflow, click + on the canvas, then pick Jump To under Add Steps.

Before you start

• An owner, admin or agent can add this step and save the workflow. Publishing it is an owner or admin action.
• Building and running workflows depends on your plan; see pricing.
• The workflow needs at least one other step already on the canvas for Jump To to point at — it cannot target itself.
• Nothing outside Inchat has to be connected. The step only changes where the run goes next.

Set up

1. Open the workflow and click + where the jump should happen.
2. Pick Jump To.
3. Under Jump to step, choose the step the run should continue at — any step already on the canvas, earlier or later.
4. Optional: change Limit jumps to a maximum of from its default of 10 (1–10).
5. Save the step, then publish the workflow.

Fields

Jump to step

The step the run continues at. Lists every step already on this workflow's canvas, including one nested inside a Condition, a Branch, a Date & Time branch, an Ask a Question lane or a Send step's failure lane.

Limits: Cannot target the Jump To step itself — the canvas refuses to save that. Targeting a step inside an Ask a Question lane or a Send step's failure lane always fails at run time — see Limits — even though the picker offers them.

Limit jumps to a maximum of

How many times this particular Jump To step may fire in one run before it stops jumping and lets the run fall through to whatever comes after it instead.

Default: 10

Limits: Clamped between 1 and 10, both when typed and when saved.

How it works

• Each Jump To step on the canvas keeps its own count of how many times it has fired in this run — a second Jump To step elsewhere in the same workflow has an independent count.
• While the step is still under its limit and the target is reachable, jumping runs the target step and everything that follows it in the target's own lane, then ends only the lane the Jump To step itself sat on — the run does not stop there: whatever comes after the step that CONTAINS the Jump To (a Condition, a Branch, a Date & Time branch) in that step's own outer lane still runs afterward, once the jumped-to portion finishes. When the jump's target sits in that same outer lane — earlier or later — the two overlap: the steps after the containing step that the jumped-to run already reached run again in the containing step's own continuation, once more for every time the jump fired, and a forward jump skips nothing — the steps it passed over still run there.
• The target can be a step nested inside a Condition, a Branch or a Date & Time branch, and can sit earlier or later than the Jump To step within the SAME uninterrupted run — but a step inside an Ask a Question lane or a Send step's failure lane can never actually be reached; see Limits.
• Once the limit is reached, the step stops jumping: the run falls through to whatever comes after the Jump To step in its own lane instead of reaching the target again.
• The count starts over at the beginning of every fresh dispatch of this workflow for the contact — not only when the trigger fires again, but at every resume too: after a Wait or an answered Ask a Question suspends and later continues the run, that continuation begins with a clean count, as if it were a new run.

When it fails

• The target step no longer exists on the canvas (it was deleted after the jump was set up), or sits inside an Ask a Question lane or a Send step's failure lane, or sits before a Wait/Ask a Question suspension point this run has already resumed past: the run logs jump target not found and falls through to the step after the Jump To step. Unlike reaching the limit, this specific outcome counts as a failed step in the run's totals.
• You read the outcome in the workflow's Activity tab: pick the run under Execution log and the step's line names what happened.

Limits

• A Jump To step's limit only bounds that one step. Two different Jump To steps in the same workflow keep separate counts, so a run can still cycle through the workflow more times than one counter alone would suggest.
• It cannot reach a step in a different workflow — that is Trigger Another Workflow's job, and it has its own, separate limit.
• It cannot reach a step inside an Ask a Question lane (Success, Invalid answer, Timeout or Message failure) or a Send step's failure lane, even though the Jump to step picker lists them — the engine's own search never looks inside those lanes, so picking one always fails with jump target not found.
• It cannot reach a step that came before a Wait or an answered Ask a Question this same run has already resumed past — once a run suspends and later continues, only the steps that were still ahead of that suspension point exist for it to jump to. A backward loop that spans a Wait or a question cannot be built with Jump To.
• The only protection against an endless loop is the per-step limit. There is no workflow-wide loop detector behind it.
• Ending the run with End does not reset or affect a Jump To step's count for a later run — the count is per dispatch from the start, not per End.

Best practices

• Avoid pointing a Jump To at a step in the same lane as the step that contains it, earlier or later — that step's own continuation still runs after the jump, so anything the jump already reached (a message, a tag) happens again, and anything a forward jump meant to skip runs anyway.
• Keep the limit low. A lower number surfaces a mistake faster than a high one.

FAQ and troubleshooting

Why did the run skip my jump and just continue?

Either the step had already reached its limit, or the target could not be reached (deleted, inside an Ask a Question lane or a Send failure lane, or before a Wait/question this run already resumed past) — all of these fall through to whatever comes after the Jump To step. Check the run's line in Activity → Execution log for which one happened.

Can I use Jump To to retry a question after a delay?

Not by jumping backward across the wait — once a Wait or an answered question suspends and resumes the run, the steps before that point no longer exist for this run to jump to. Build the retry as a new Ask a Question inside the invalid-answer path instead.

Can Jump To send the contact to a different workflow?

No. It only moves between steps on the same canvas. To hand the conversation to another workflow, use Trigger Another Workflow.

Related

• Trigger Another Workflow — Hand the conversation to another published workflow, from its first step or a chosen one, so a large design can stay several small workflows instead of one long flow.
• Condition — Split the run into up to twelve lanes plus a None lane, checked top to bottom — the first lane whose conditions all pass wins, and Condition tests one field against one value at a time.
• End — Stop the run right here — including whatever sits further out than the lane the End step is nested in, such as a Condition branch or a Date & Time branch.
• Avoid workflow loops — What already stops a flow from re-triggering itself, and the two hard caps — on Jump To and on Trigger Another Workflow — that stop a deliberate loop from running forever.
• Workflows: how a flow runs — A workflow is one trigger, optional conditions and an ordered list of steps; only a published workflow runs, and this article explains how a run starts, forks, pauses, fails and stops.