Flows
A flow is the conversational unit the AI runs for a given customer journey — "where is my order," a return request, a lead qualification, a warranty check. Everything the AI does inside that journey (what it asks, what it looks up, when it branches, when it hands off, when it closes) is defined by the flow's configuration.
You rarely edit these options in a form. In practice the team builds and changes flows by chatting with the Copilot — but understanding the options below helps you phrase requests precisely and read what a flow actually does.
How a flow is chosen
When a customer message arrives, the AI decides which flow to run by matching the message against each flow's trigger description — a short prompt describing when this flow applies (for example, "customer is asking about the status or location of their order"). Write the description in terms of customer intent, not internal jargon.
- A flow can be marked trigger-only, so it never starts from a plain customer message — it runs only when another flow routes into it (a transition) or an outreach event fires it (a WhatsApp template reply or an outgoing flow message).
- A flow can carry an opening message that's sent when it starts, and general notes to the AI that stay in effect for the whole time the flow is active (tone, do's and don'ts, context the AI should keep in mind).
Objectives — the heart of a flow
A flow is mostly a list of objectives. An objective is one thing the AI needs to do or know in the conversation. Objectives come in a few kinds, and mixing them is how you shape the dialogue.
| Kind | What it does |
|---|---|
| Ask the customer | The AI asks a question and collects the answer (order ID, reason for return, an image). |
| Inferred | The AI works the value out from the conversation and context without asking — its value description tells it how to extract or determine the value. |
| Data point | Pulls a value into the conversation from a lookup — order status, days since delivery, customer address. See Data Points. |
| Execute action | Performs a side effect — create a ticket in Freshdesk, cancel an order, send a notification. See Data Points. |
| Computed | A deterministic value calculated from other objectives already collected (no external call). |
| Human agent | Hands this step to a human — creates a child ticket and routes it to a team. |
Asking the customer
For an ask-the-customer objective, the key options are:
- Ask instruction — how the AI should phrase the question. This is guidance, not a fixed script; the AI adapts it to the conversation.
- Answer options — offer the customer a bounded set of choices instead of free text. Options can render as quick-reply buttons or a dropdown, and you can present a value differently to the customer than you store internally (a friendly label mapped to an internal value).
- Special inputs — instead of text, ask for an address form, a location, a WhatsApp Flow form, or a product recommendation picker.
- Deterministic answer matching — for bounded answers, map exact customer phrases to a value ("yes/yeah/yup" →
yes) so the answer is captured reliably without relying on inference. - Ask at least once / skip conditions — force the question to be asked at least once, or skip it entirely when a condition is already satisfied.
- Allowed values — constrain what counts as a valid answer, with a format or validation rule (for example, "a valid date in
yyyy-mm-ddformat").
Making objectives conditional
Objectives don't have to be flat. Two mechanisms control when an objective applies:
- Required condition — whether an objective must be completed, optionally depending on another objective's value. For example, "only require an invoice image when the reason is damaged."
- Parent condition — activate a group of child objectives only when a parent objective meets a condition. This is how you build branches: ask the follow-up questions for "damaged" only when the customer said the item was damaged.
Conditions compare an objective's value using operators like equals / not equals, contains / not contains, greater than / less than, in (one of a set), matches a pattern, exists / has a valid value, or the API failed.
Handing a step to a human
A human-agent objective creates a child ticket and routes it to a team. You can configure:
- The customer-facing message shown when the step is handed off.
- A hint for the agent in their console.
- Whether the agent must record a resolution, an optional resolution hint, and whether that resolution is shared back with the customer as a note.
See Child & Interaction Tickets and Teams & Assignment for how the routed work behaves.
Transitions — branching and early exit
Transitions let a flow change course based on an objective's value:
- Route to another flow — when the customer's answer means a different journey should take over (a return request that turns out to be a warranty claim).
- Complete early — end the flow as soon as a condition is met, with its own completion message.
- Send a reply and continue — drop in an extra message when a condition is met without leaving the flow.
Each transition names the objective to watch, the condition to evaluate (same operators as above), and where to go. A flow can also be set to only allow transitions — it never matches a plain customer message and only moves via routing.
Passive context
Beyond objectives, a flow can include data points as passive context — values injected into the AI's context for the whole conversation without being collected step by step (for example, always having the customer's order count available). These are the same data points documented in Data Points; the difference is they're along for the ride rather than a step the AI works through.
Completion & handoff
When the objectives are done, the flow's completion behavior decides what happens:
- Completion prompt — instructs the AI what to tell the customer once the flow's objectives are complete, using everything it collected.
- Run completion independently — send the completion message on its own rather than blending it with other replies.
- Resolve or assign — automatically resolve the ticket, or hand it to a human on completion. By default a flow that isn't set to auto-resolve leaves a ticket for an agent.
- Completion action — optionally run an execute action when the flow completes.
- Follow-ups — schedule follow-up messages after completion.
- Disposition presets — preset ticket disposition fields (category, sub-category, and other values) whenever this flow runs, so tickets are classified consistently.
How the pieces shape the conversation
Read together, the configuration is the conversation:
- The trigger description decides whether this flow runs at all.
- Objectives drive the turn-by-turn dialogue — what the AI asks, what it silently infers, what it looks up, and what it does.
- Conditions (required and parent) decide which objectives apply, so the customer only sees the questions relevant to their situation.
- Transitions reroute or end the flow the moment the situation changes.
- Completion decides how the journey ends — a message, a resolved ticket, or a handoff to a human.
Change any of these and the customer's experience changes accordingly — which is exactly what you're doing when you ask the Copilot to "add a follow-up question when the reason is damaged" or "route refunds over ₹5000 to the retention team."
Building & testing flows
- Add and edit flows conversationally with the Copilot — it can read every configured flow, explain how a journey is handled, and make changes for you.
- Reuse common logic with the Objective Library — mark an objective as shared to import it into other flows. See Workflows → Data Library.
- Try a flow before relying on it with the Test flow feature, and lock in behavior with automated test runs.
Related
- Workflows — the umbrella view of flows, the data library, samples, products, and stores.
- Data Points — the values and actions a flow's objectives use.
- Custom APIs — where flow lookups and actions get real data.
- Copilot — build and change flows by chatting.
- Testing — automated, repeatable tests with assertions and mocking.