Overview

Use flows for important, structured interactions.

Use flows when you need to guide a caller through a structured process — collecting a booking reference, routing based on account type, or verifying identity before transferring. Without flows, multi-step interactions rely on the LLM to improvise sequence and validation, which leads to inconsistent outcomes and missed data.

Flows are found under Build > Flows in Agent Studio.

Use Managed Topics for simple question-and-answer interactions. Use flows when the conversation requires a specific sequence of steps, input validation, or branching logic.

Some parts of this page include Python code. You can build flows without writing any code — see no-code flows. Code examples below are for developers who need programmatic control over flow routing. If you are a non-technical user, you can safely skip the code sections or share them with your developer.

How to trigger a flow

There are a few common ways to start a flow. The right choice depends on where you are in the product and how deterministic you need the trigger to be.

1) Trigger an existing flow from code

Use this when you are in a function and you want to start a flow deterministically. This approach requires Python familiarity.

Example:

    conv.goto_flow("Reservation flow")

This starts the named flow on the next turn.

2) Create a flow from within a Managed Topics action

Type /Flow and then use the plus sign (+) to start this process.

3) Trigger a flow from inside another flow

Use this when the user is already in a flow and you want to switch to another structured interaction (for example, escalation, payments, identity verification, or a separate task).

Typical pattern:

• You use a Function step (or a transition function) and call conv.goto_flow to move into a different flow

APIs do not trigger flows directly. Instead, flows orchestrate steps, and Function steps can call APIs. If an API result should change the path, you use code to route or start the appropriate flow.

How flows work

Each flow is made up of:

• Steps: Self-contained conversation states, made up of:
  • Text prompts, just like Knowledge topics.
  • Global functions and transition functions: Logic blocks that validate input, call APIs, store values, and move the conversation forward.

That means as each step is sequentially processed, the LLM sees:

• The current step’s text prompt.
• A list of available functions with names, descriptions, and arguments.

What the LLM doesn’t see:

• Previous step prompts.
• Any system context, unless it’s surfaced in the prompt or state.

Because previous steps are not visible, each prompt must be self-contained. Provide all necessary context and clear guidance in each step.

LLM interaction model

When the agent is inside a flow step, this is the input order:

1. System prompt (includes Rules and Agent agent configuration).
2. Any relevant Knowledge topics (if applicable).

Knowledge function visibility in flows

To make global Knowledge functions available while a flow is running, enable this in your agent’s Voice configuration or Chat configuration settings (under the advanced LLM configuration section). Contact your PolyAI representative if you need help enabling this setting.

Key techniques

The following techniques involve writing Python code. Expand Code-driven flows in the sidebar, or visit the Developer tab for all code content in one place.

• Transition functions control the flow’s routing logic.
• Use few-shot prompting to clarify expected inputs or edge cases.
• Set ASR biasing to improve voice transcription for structured or ambiguous values like confirmation codes or personal names. Learn more about ASR (automatic speech recognition).
• Use variables to store and reference data across steps.

Connecting steps

In the Flow Editor:

• Use /Steps in the prompt to connect to the next step
• Add named transition functions to manage movement between states
• Use the Flow Functions modal to see all transitions in one place

Always include an exit step in your flow. Un-exited flows can cause hallucinations.

Use descriptive function names like check_reservation_match, not vague ones like step_two — this helps the LLM reason correctly.

Standard entity types

Entity types define the kind of information your agent collects from users. They help the system validate and structure input once it has been recognized by ASR.

Available types

Type	Description	Configurable options
Alphanumeric	Any mix of letters and numbers. Useful for booking references or codes.	Regex validation (built-in zip/postal code presets or custom)
Number	Numeric values.	Integer vs decimal, min/max range
Date	Calendar dates.	Day-first toggle, start/end date range
Time	Clock times.	Start/end time range
Phone number	Telephone numbers.	Restrict by country code
Name	Personal names.	—
Address	Street addresses or locations.	—
Free text	Open-ended responses without validation.	—
Email	Email addresses.	—
Multiple choice	Selection from predefined options.	Accepted values list

For full configuration details per entity type, see no-code flows — entity types.

Further reading

Example flow

A complete reservation confirmation flow with step-by-step walkthrough.

No-code flows

Build flows visually with prompts and entity extraction — no Python required.

Transition functions

Write Python logic to control how your agent moves between steps.

ASR biasing

Improve voice transcription accuracy for structured inputs.

Few-shot prompting

Use examples in prompts to improve accuracy and reduce ambiguity.

Flow object

Python reference for goto_step() and current_step.