# 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.

## 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](/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

| Field | What it means | Default | Limits |
| --- | --- | --- | --- |
| 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. | — | 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. | 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](https://inchat.inseller.my/help/workflows/jump-to)
- [Avoid workflow loops](https://inchat.inseller.my/help/workflows/avoid-workflow-loops)
- [Test and publish a workflow](https://inchat.inseller.my/help/workflows/test-and-publish)
- [End](https://inchat.inseller.my/help/workflows/end)
- [Workflows: how a flow runs](https://inchat.inseller.my/help/workflows/workflows-overview)

---

Source files: `src/lib/workflows/ai-builder/spec.ts`, `src/lib/workflows/canvas-model.ts`, `src/components/workflows/WorkflowStepConfigDrawer.tsx`, `src/lib/workflows/engine-contracts.ts`, `src/lib/workflows/workflow-targets.ts`, `src/lib/workflows/engine.ts`, `src/lib/workflows/types.ts`, `src/lib/workflows/engine.test.ts`, `src/app/(app)/workflows/WorkflowToggle.tsx`, `src/lib/i18n/messages/workflows-publish.ts`, `src/app/(app)/workflows/[id]/page.tsx`