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-dd format").

Presenting a WhatsApp Flow form

A WhatsApp Flow form objective is an ask-the-customer objective that opens a published WhatsApp Flow instead of collecting each field through separate chat messages. The objective still has one normal objective value: the submitted form response completes that objective and the conversational flow continues to its next eligible objective.

Configure three parts together:

• Ask instruction — frames the short message sent with the attached form. For a newly configured form, make this an invitation to complete the form; do not list every form field in chat.
• WhatsApp Flow — the published Flow ID to attach.
• Enabled channels — the customer channels that can render this interaction. WhatsApp is currently the only supported option and is selected by default for a new Flow form objective.

Channel eligibility applies to the whole objective, not only to its button. On email, Instagram, chat widget, voice, and other unsupported channels, the Flow form objective is skipped for that invocation: it is not inferred, is not counted as asked, and does not block a later eligible objective. A flow containing only skipped objectives can complete normally. Manual ticket creation also skips channel-scoped Flow form objectives even when the selected ticket source is WhatsApp; the manual form does not show those objective fields.

Skipping is temporary and is not saved as an objective skip policy. If the same customer journey later continues on WhatsApp, the objective can become eligible and present the form. Ordinary objectives without an enabled-channel restriction continue to work on every supported channel.

Customer message compatibility

New Flow form objectives frame the attached-form message from their Ask instruction. The Legacy: frame the message from Flow metadata setting additionally applies the Flow's saved customer-message instruction. Keep this enabled only when an existing form relies on that metadata for its wording.

Existing Flow form objectives remain backward compatible: when their newer channel/message settings are absent, they are treated as WhatsApp-only with legacy metadata messaging enabled. This preserves their WhatsApp wording while intentionally preventing the form from appearing in unsupported channels. Turning off the legacy setting changes message framing only; it does not change the attached Flow or its submitted data.

Prefilling form fields

Field-level prefill maps one already-available objective value into one exact Flow field:

Flow screen: CONTACT
Flow field: phone_number
Source objective: customerPhone

When the form is sent, a valid customerPhone output is placed in the Flow's corresponding initial-data key (for example, prefill_CONTACT_phone_number). Values are passed as collected; a mapping does not transform or reformat them. If the source objective is missing, inactive, null, or a blank string, the target field stays blank and the form still opens.

For reliable prefilling:

1. Make the target field prefill-ready in the WhatsApp Flow, then publish or republish the Flow. A task mapping cannot prefill a field whose Flow definition has no initial-data binding.
2. Use the Flow's exact screen ID and field name in the mapping.
3. Make the source objective available before the form objective runs. Prefilling reads the current task output; it does not ask, fetch, or calculate the source by itself.
4. Keep the source value compatible with the Flow field type. No coercion is added at send time.

The library editor also offers Prefill with data for supported built-in customer values such as customer name, phone number, address, or PIN code. Use field-level mappings when the value comes from a specific task objective or when several fields need different task outputs.

When a form and its source objectives are reused as an Objective Collection, include every source named by its prefill mappings in that collection and keep those sources before the form objective.

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 Agent Assignement & Team 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:

1. The trigger description decides whether this flow runs at all.
2. Objectives drive the turn-by-turn dialogue — what the AI asks, what it silently infers, what it looks up, and what it does.
3. Conditions (required and parent) decide which objectives apply, so the customer only sees the questions relevant to their situation.
4. Transitions reroute or end the flow the moment the situation changes.
5. 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.
• Reuse a group of objectives and its internal wiring with a live-linked Objective Collection. Linked members collect ticket values under the same objective params as ordinary flow objectives.
• 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.
• Objective Collections — live-link reusable objective groups across flows.
• 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.