Skip to main content

Build & Change Flows

This is where the Copilot does the heavy lifting: it builds and edits the conversational logic itself — the flows customers move through, the data points those flows use, and the reusable templates that hand work to a human. Instead of filling in every field by hand, you describe the behavior you want and the Copilot assembles the configuration, creating any missing data point or API along the way.

For the full configuration reference, see Flows and Data Points.

What a flow is made of​

Knowing the pieces helps you ask for exactly what you want. A flow has:

  • A trigger — a description of the customer intent that starts it (e.g. "customer wants to cancel an order"). This is what the AI matches against what the customer says.
  • Objectives — the things the flow collects or does, in order: questions to the customer, values fetched from a data point, actions to run, or a handoff to a human.
  • Child tickets — the objectives that hand a step to a human agent. When a flow needs manual verification, an approval, or a judgment call, that step opens a child ticket for an agent to resolve; the flow waits for their answer before it continues. These can be saved as reusable templates (see below).
  • Branching — transitions and conditions that send the conversation down different paths or end it early based on an objective's value.
  • Completion — the message sent when the flow finishes, and whether it closes the ticket or assigns it to a team.

When you build, you're really describing these four things. The more of them you name, the closer the first draft lands.

Create, update, or delete flows​

Describe the intent that should trigger the flow, what it needs to collect, how it should branch, and how it ends.

"Create a flow that handles refund requests by handing off to the retention team." "Update the warranty flow to also ask for an invoice image." "In the cancellation flow, if the order has already shipped, tell the customer we can't cancel and end there." "Add a branch: if the customer says the item is damaged, ask for a photo before escalating." "purchase_date should be a valid date in yyyy-mm-dd format."

What to include for a good first draft:

  • The trigger — what does the customer say or want that should start this flow?
  • What to collect — order id, a photo, a reason, a confirmation, etc.
  • Where it branches — "if eligible… otherwise…", and what happens on each path.
  • The outcome — auto-resolve with a message, or hand off to a specific team.

If a change needs a data point or API that doesn't exist yet, the Copilot plans that prerequisite first and tells you — you don't have to create it separately.

Create, update, or delete data points​

Data points are the named values (useData) and actions (executeAction) a flow uses — order status, a serviceability check, a create-shipment call. They live in the Data Library and can be reused across flows. Ask the Copilot to add one, remap its inputs, or change how it handles missing values.

"Add a data point that fetches order status." "Change the pincode input on the serviceability check to service_address_pincode." "sku_id should return unavailable when it can't be extracted." "Make the refund amount a data point so other flows can reuse it."

Some values are built in and always available (customer name, selected order, uploaded images). Others are configured and backed by a custom API. See Data Points for the full list and how each is sourced.

Manage reusable child-ticket templates​

When a step needs a human — manual verification, an approval, a judgment call — it becomes a child ticket for an agent. You can save these as reusable objective templates so the same handoff can be dropped into many flows.

"Create a reusable child-ticket objective for manual address verification." "Add an approval step to the refund flow where an agent confirms the amount before we proceed."

Things worth knowing before you build​

A few behaviors shape how flows actually run — asking with these in mind avoids surprises:

  • Questions are asked one at a time, in order. The flow won't move to the next question until the current one has a valid answer. Order your objectives the way you want the conversation to go.
  • Order-backed data needs a selected order. Anything that reads order details requires the customer to have selected an order first, so the flow will collect that before it can fetch order data.
  • The AI can't claim an action happened unless it actually ran. It will only confirm "your refund is processed" when a real execute action returned success, or when a human is handling it — so if you want a confirmation, there has to be an action or handoff behind it.
  • Branch order matters. When more than one branch could apply, the first matching one wins. Ask for the higher-priority case first.
  • Name the exact thing you're editing. "Edit the data point, not the API" or "change the trigger, not the completion message" keeps an edit from landing in the wrong place.

After you build​

A new or changed flow is configuration you should confirm before customers hit it. Run it through the Test flow preview for a quick check, or save it as an automated test so the behavior stays locked down as you keep editing.