Overview

What a trigger is

A trigger is a small piece of automation attached to a flow that runs in the background when a conversation reaches a moment in its lifecycle, with no customer waiting on the other end. Where your main flow is a conversation (it asks questions, presents choices, sends messages), a trigger is a side-effect: it might POST to your CRM when a chat closes, generate an internal summary, or branch on a condition and call one of two webhooks.

Triggers live in the same flow editor as your conversation, on their own tabs alongside Main Flow. Each trigger is tied to one lifecycle event, and a flow can have at most one trigger per event.

Lifecycle events

A trigger fires on exactly one of these conversation events:

A completed or abandoned conversation also fires Conversation Closed, so a single trigger on Closed catches every meaningful ending. A timed-out bounce fires only Conversation Timed Out.

Trigger-safe nodes

Because a trigger runs with no customer present, it can only use nodes that don't try to talk to anyone. The palette on a trigger tab is restricted to these trigger-safe nodes:

• Start: the entry point of the trigger.
• Condition: branch on data (for example, only notify for high-value carts).
• API Request: call an external service.
• Content Generator: produce text or structured data with AI.
• Intent Recognition: classify the conversation's intent and route accordingly.
• RAG Retriever: search your knowledge base and surface relevant chunks.
• Agentic RAG Retriever: multi-hop knowledge search with AI-driven query planning.

Draft, then enable

Every trigger starts life disabled, as a draft. While it's disabled you can save it in any state, half-finished and all, without anything firing. The toolbar shows a Disabled toggle for the trigger you're editing.

When you flip it to Enabled, the trigger's graph is validated. To enable, it must:

• use only trigger-safe nodes,
• have a single entry point (every other node connected, none left dangling), and
• have valid configuration on each node (for example, an API Request needs an endpoint).

If anything is wrong, enabling is refused and the editor tells you what to fix. Outgoing connections aren't required; a node can be the end of the line.

How a trigger fires

Once enabled, a trigger fires automatically whenever its event happens, in the background, so it never slows the conversation down. It runs against the same version of the flow the conversation is using, so changes you publish don't retroactively alter conversations already in flight.

Each occurrence of an event runs the trigger at most once. The occurrence is claimed the moment the run starts, so a duplicate of the same event won't run it again, and a run that fails is recorded as failed rather than retried. A different occurrence of the same event counts on its own and fires again: if a closed conversation is reopened and later closes a second time, that second close is its own occurrence, so the trigger fires once more.