Avoid workflow loops

Getting here

Automate → Workflows

Before you start

• An owner, admin or agent can build and save a workflow; see workflows-overview for who can publish one.
• Building workflows depends on your plan; see pricing.

How it works

• A step that sends is stamped as sent by the system or by the AI agent, never as a customer message — so a Send a Message, AI Reply or any other send a flow makes never re-fires Message Received on that same message. A workflow cannot trigger itself this way, by construction.
• The same workflow answering the same conversation again is separately throttled: a short cooldown (about 10 minutes) after a run suppresses a second run of that exact workflow on that exact conversation, even if its trigger's event happens again inside that window. A handful of triggers that name each event individually — a tag or field change, a video's watch threshold — are exempt from this specific cooldown.
• Jump To is the one step meant to loop on purpose. The engine counts how many times each Jump To on the canvas has actually jumped in THIS run and stops following it once that count reaches the lower of 10 and whatever the step's own max jumps field asks for — the field can lower the cap, never raise it past 10. The count lives only in that run's state, so it starts fresh every time the run resumes from a Wait or an answered Ask a Question — it does not remember jumps made before the pause.
• Trigger Another Workflow refuses to hand off to a workflow that is already running inside the same chain — including handing off to itself — the very first time, not after some number of attempts. Two workflows that hand off to each other are refused on the second one, not allowed to swap back and forth a few times first.
• Beyond that, a chain of Trigger Another Workflow hand-offs (A hands to B, B hands to C, …) is capped at 5 workflows deep; a hand-off that would go deeper is refused rather than followed.
• A Trigger Another Workflow hand-off runs the target workflow inline, inside the same turn as the flow that called it — it is not a second, later trigger — so it does not get a fresh cooldown window of its own and does not re-enter the real-time dispatch loop that matches triggers to events.

When it fails

• A Jump To that hits its cap does not fail the run: it is marked ok in the run log (hover the step for jump limit reached), and the flow falls through to whatever step comes after that Jump To in the same list, exactly as if the jump had not been there.
• A Jump To placed after a Wait that actually suspends the run — its total short waits past 15 seconds, or one set to a clock time — or after an Ask a Question, fails with jump target not found if it targets a step from BEFORE that pause: a resumed run only carries the rest of the flow that was saved when it paused, not the steps that already ran before it. A short Wait runs inline only while the run's short waits add up to 15 seconds or less in total; past that it suspends like a long one. So a loop through a short Wait can jump back once or twice, then fails with jump target not found once the total passes 15 seconds.
• A Trigger Another Workflow refused for re-entering its own chain, or for going past the chain depth cap, is recorded as one failed step — the reason is on that step's line in the Activity tab's Execution log — and the rest of the calling flow after that step still runs.
• A Trigger Another Workflow that hands to a workflow which is not published, no longer exists, or (when it names a specific step to continue at) whose named step no longer exists is refused the same way, with its own reason on the step's log line.

Limits

• The cooldown only protects one (workflow, conversation) pair. It does nothing for two different published workflows that both match the same trigger — each one gets to run its own copy of the same protections independently, so a customer can still be answered by more than one flow on the same event.
• Nothing counts how many DIFFERENT workflows a single conversation has been handed through outside a Trigger Another Workflow chain — the chain cap only limits hand-offs made with that one step type.
• None of this stops a flow from feeling repetitive to a customer for reasons that are not a loop at all — for example, two unrelated published workflows that each send their own message on the same trigger. That is a design problem for Workflows: how a flow runs to cover, not something a loop cap catches.

Related

• 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.
• 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.
• Conditions and variables — How a condition decides whether a workflow starts or which path a contact takes, and how a {{variable}} is filled into the text a workflow sends.