Flows: Build Multi-Step Chatbot Scenarios Visually

Sometimes a conversation needs more than a single AI answer: collect a few details, look something up in your systems, then act on it. Flows is a visual builder where you compose those scenarios as a graph of steps — a trigger that starts the flow, then condition and action nodes that run in order. Two examples of what a flow can do:

• Multi-source answer — a visitor asks a question → the flow searches your Discourse forum and your CRM via Custom Tools → the AI aggregates the results into one answer.
• Ticket intake — the flow asks for email, company, and the problem → submits everything to your webhook → notifies your team.

Flows consolidate four older features into one canvas:

• Smart Triggers → a page_behavior trigger + ai_message node
• Human handoff scenarios → a visitor_intent trigger + request_human node
• Forms → embedded in a flow with a show_form node
• Cart Recovery → a cart_abandoned trigger + delay + cart_recovery_touch nodes

The old Smart Triggers, Forms, and Cart Recovery pages redirect here — everything is built and edited in the flow editor.

​

How Flows work

1. A trigger starts a run — either a visitor message that matches your intent description, or an event like a form submission.
2. The flow walks the graph node by node: asking questions, branching on conditions, calling tools and webhooks, sending messages.
3. While a flow is running or waiting for the visitor’s answer, it owns the conversation — the visitor’s replies resume the flow instead of going to the AI.
4. The run ends when the graph ends, when an AI respond node hands the collected results to the chatbot for a final answer, or when the visitor cancels (“cancel”, “stop”, “never mind”).

​

Triggers

Every flow has exactly one trigger — the first node on the canvas. visitor_intent and page_behavior are the chat triggers: the flow runs inside the conversation and can talk to the visitor. The others are event triggers that run in the background. Event triggers that carry a conversation (form_submitted, conversation_started, handoff_requested) can still message the visitor; conversation_rated, lead_captured, cart_abandoned, and inbound_webhook have no conversation, so chat nodes aren’t allowed under them — the editor enforces this.

​

Page behavior triggers

A page_behavior trigger turns the flow into a proactive opener: the widget watches the visitor’s page behavior and, when it matches, the flow starts a conversation with an AI-personalized message. Config: subtype, urlMatchType (exact/contains/prefix/regex), urlPatterns, dwellSeconds, cooldownMinutes, sortOrder, plus config for e-commerce subtypes (thresholdCents, minCartCents, currency). Pair it with an ai_message node — the AI personalizes your template with page context and falls back to the template verbatim if the model is unavailable.

​

Node catalog

Nodes are the steps of your flow. Drag them from the palette onto the canvas and connect them.

​

Variables and {{var}} interpolation

Every value a flow collects — visitor replies, form submissions, tool results, webhook responses — is stored in a named variable. Use {{variable}} (or a nested path like {{order.status}}) inside any message, question, webhook body, or email to insert the value. The trigger’s payload is available as {{trigger}}. Missing variables resolve to an empty string.

​

Build a flow

​

Test before activating

The editor’s Test panel runs the flow without touching real conversations. Clicking Test saves any pending canvas edits first, so the run always exercises what you see.

• For visitor_intent flows, a chat-style transcript lets you play the visitor — send messages, answer the flow’s questions, and watch each step’s status. The panel reports the intent-match score your message would get in production, and typing “cancel” or “stop” exercises the same escape hatch visitors have. show_form nodes render the real form inline — submitting it resumes the run, and an ai_respond node previews the actual AI reply.
• For event triggers, fire a test event with a JSON payload preview. If the run then waits on a chat node (collect_input, show_form), the input row switches to a chat box so you can continue the run like a visitor.
• While a test runs, the canvas highlights the executed path — green for completed nodes, red for failures, and a pulsing amber ring on the node the run is waiting on.
• Each step in the trace expands to show its exact input and output JSON, so you can see what data flowed between nodes. Steps that touch the outside world (run_tool, call_webhook, send_email, notify_team, request_human) carry a live badge.

​

Runs and history

Every execution is recorded as a run. Open a flow’s Runs page to see each run’s status (running, waiting, completed, failed, cancelled), when it started, and a per-step trace showing every node’s input, output, or error — the fastest way to debug a flow that didn’t behave as expected. A run that waits more than 24 hours for a visitor reply is cancelled automatically — timer waits on a delay node are exempt and resume when the timer fires. A visitor can always escape a waiting flow by saying “cancel” or “stop” — the conversation then goes back to the normal AI.

​

Debug and troubleshoot

When a flow misbehaves, work through it in this order:

1. Reproduce in the Test panel. The transcript, intent-match score, and canvas highlight show exactly which path executed. Expand each step’s input/output to see the data it received and produced.
2. Check the Runs page. Every real and test execution is recorded. A failed step shows its error inline; a waiting run means the flow is parked on a collect_input or show_form node expecting a visitor reply.
3. Common causes:
   • Flow never triggers — the visitor’s phrasing doesn’t match the intent closely enough. Test the exact message in the panel; if the score is below the 0.6 threshold, broaden the intent description.
   • Flow stops mid-run — a waiting status means it’s waiting for input, not broken. Check whether the visitor escaped with “cancel”/“stop” (status cancelled) or the run timed out after 24h.
   • Webhook/tool step failed — expand the step output for the HTTP status or error. Test webhooks against a service like webhook.site first.
   • AI reply looks wrong — ai_respond composes from the collected variables; check the step inputs to confirm the right values were captured, and tighten the node’s instructions.

​

Example flows

Six recipes to copy — each is a chain of nodes you can build in a few minutes.

​

Lead qualification

visitor_intent (“interested in pricing / wants a quote”) → collect_input email (expected: email) → collect_input company → call_webhook to your CRM → notify_team → send_message confirmation. The visitor asks about pricing, the flow collects their email and company, posts the lead to your CRM, pings your team, and confirms to the visitor — all inside one conversation.

​

Proactive opener (Smart Trigger)

page_behavior (time_on_page, 30s on /pricing*) → ai_message template → ai_respond. The widget watches visitors dwell on your pricing page, opens the chat with an AI-personalized opener, then lets the chatbot answer follow-ups. This is the old Smart Triggers pattern as a flow.

​

Human handoff

visitor_intent (“wants to speak to a human / asks for sales”) → collect_input email → request_human. The old handoff-scenario pattern: the flow matches the visitor’s intent, optionally collects contact details first, then creates a live-support ticket so a teammate can take over with the full transcript attached. See Human handoff.

​

Form in a flow

visitor_intent (“wants a demo / wants to sign up”) → show_form (your signup form) → send_message confirmation. Instead of the AI deciding when to surface a form, the flow controls it: the form renders in chat at exactly the step you place it, and the submission lands in a variable you can pass to a webhook or email downstream.

​

Ticket intake (event)

inbound_webhook → condition on {{trigger.priority}} → send_email to support / notify_team. Your backend POSTs a ticket payload to the flow’s webhook URL; the flow routes high-priority tickets to the support inbox and notifies the team about the rest. Event triggers have no visitor conversation, so only non-chat nodes are used.

​

Cart recovery (Shopify)

cart_abandoned → delay 60m → cart_recovery_touch → delay 24h → cart_recovery_touch. Every synced abandoned checkout starts a run: the flow waits an hour, sends an AI-written recovery message (chat widget if the visitor is still around, email otherwise), waits a day, then sends one follow-up. A completed purchase cancels the run mid-wait. See Shopify.

​

Best practices

• Write intents like a visitor would phrase them — “wants to speak to sales”, not “sales intent trigger”.
• Collect one thing per collect_input — short questions get better answers, and each answer lands in its own variable.
• Set expected when the answer has a shape — email, phone, order number — so the flow re-asks once instead of storing “I don’t know”.
• End chat flows with ai_respond or send_message — don’t leave the visitor hanging on a silent last step.
• Test with real-looking data — run_tool and call_webhook hit your real endpoints even in test runs.

​

Plans & limits

Flows require a Pro plan or higher. There’s no limit on the number of flows per website. Flow messages count toward your plan’s message quota like any bot reply. See Billing & Plans for details.

​

Related