Trigger Another Workflow

Getting here

Automate → Workflows, open a workflow, click + on the canvas, then pick Trigger Another Workflow 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 target workflow must exist in this workspace. It can still be a draft or stopped while you build, but this workflow cannot be published until the target is published.

Set up

1. Open the workflow and click + where the hand-off belongs.
2. Pick Trigger Another Workflow.
3. Under Select a workflow, choose the target. A target that is not published shows its status next to its name.
4. Optional, if the target has steps: under Workflow step, choose where to start — the default is Start from the beginning.
5. Save the step, then publish the workflow — publishing is refused while the target is unpublished or the hand-off would loop back here.

Fields

Select a workflow

The target workflow this step hands the conversation to. Every OTHER workflow in the workspace is listed, whatever its status — never this same workflow.

Limits: If the previously chosen target has since been deleted, the field shows A workflow that no longer exists instead.

Workflow step

Where in the target workflow the hand-off starts. Only shown when the target has steps to choose from.

Default: Start from the beginning

How it works

• Running this step runs the target workflow for this conversation right now, starting at its first step or the chosen one — the target's own trigger is not consulted, so a target built on any trigger type can be reached this way.
• The target runs with its own fresh execution state, so its own waits and questions belong to it, not to the workflow that triggered it.
• This step waits for the target's run to finish before the calling workflow's own next step runs — it is a hand-off the calling workflow waits on, not a fire-and-forget signal.
• If the target's own run sent the customer a message, that counts as this run having replied too, so the inbound dispatcher does not let a second automation answer the same inbound on top of it.
• The target workflow must be published at the moment this step actually runs, not only when this workflow was published — a target that has since been unpublished or stopped makes the step fail instead of running it anyway.
• A hand-off that would re-enter a workflow already running in this chain — the target itself, or one further back that led here — is refused rather than run, and a chain of hand-offs can go no more than 5 workflows deep.

When it fails

• The target is not published when the step runs: the step fails and the reason names its current status, and the calling workflow's run continues to its own next step.
• The target no longer exists, or belongs to a different workspace: the step fails with that workflow no longer exists.
• The hand-off would re-enter a workflow already running in this chain: the step fails rather than looping, and the calling workflow's run continues to its own next step.
• The chain of hand-offs has already reached 5 workflows deep: the step fails and the run does not go any further down that chain.
• The chosen Workflow step was deleted in the target, OR it sits inside the target's own Ask a Question or Send-failure lane — the same lanes Jump To can never reach: the step fails either way with the step it continues at is no longer in “<target name>”, which reads like a deletion even when it is not.
• You read the reason in the workflow's Activity tab: pick the run under Execution log and the step's line names it.

Limits

• The target workflow's own trigger conditions are never evaluated by this step — building the target on a Manual trigger is a convention for clarity, not something this step requires or checks.
• The publish-time check that refuses a hand-off looping back here only follows a target picked by name in the list. A workflow duplicated from a template that resolves its hand-off by name at run time is not covered by that check — a loop built that way is only caught when it actually happens, mid-conversation, by the same-run guard above.
• The calling workflow's own next step still runs after this one, whatever the target did — with one exception: if the target's run left the customer's delivery outcome unknown (a send whose result could not be confirmed), the calling workflow's run stops there too, the same way that send would have stopped it directly.
• Select a workflow never offers this same workflow as its own target, so the picker cannot be used to make a workflow hand off to itself; only an indirect loop through other workflows is possible to build by accident.
• The Workflow step picker lists every step in the target, including ones inside its Ask a Question and Send-failure lanes — but picking one of those always fails at run time, the same gap Jump To has, since both use the same underlying step lookup.

Best practices

• Split a workflow once it is hard to read on one canvas, and hand off with this step rather than nesting everything in one long design.
• Before publishing a change to a workflow other workflows hand off to, check who hands off to it — publishing itself does not warn you. Stopping or deleting it does: the confirmation lists every published workflow that hands off to it.

Use cases

• A lead-capture workflow qualifies a contact, then hands off to a nurture workflow built and owned separately.
• Several entry points — an ad reply, a website form, a WhatsApp broadcast reply — each run their own short workflow, then all hand off to one shared onboarding workflow.

FAQ and troubleshooting

Does the calling workflow keep running after the hand-off?

Usually — this step waits for the target's run to finish, then the calling workflow continues to its own next step. The one exception is when the target's own run left the customer's delivery outcome unknown; then the calling workflow's run stops there too.

Can I hand off to a workflow that is still a draft?

You can connect it while building, but this workflow cannot be published until the target is published, and the hand-off fails at run time if the target still is not.

What stops workflow A and workflow B triggering each other forever?

A hand-off that would re-enter a workflow already running in this chain is refused rather than run, and the whole chain is capped at 5 workflows deep. Publishing also refuses a loop back to this workflow — direct or through a longer chain of other workflows — when every hand-off in that chain is picked from the list rather than resolved by name.

I stopped a workflow other flows hand off to — will anything tell me?

Yes. Stopping (and deleting) shows a confirmation listing every published workflow that hands off to it before you confirm. Publishing a change to it does not carry the same warning.

Related

• Jump To — Send the run straight to another step already on the canvas, forward or backward, capped by a per-step limit so a deliberate loop cannot run forever.
• 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.
• Test and publish a workflow — Plan a workflow's path against a pretend conversation without sending anything, then publish it — and know what Publish refuses, what it only warns about, and what it locks.
• 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.
• 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.