Skip to main content
rules-examples No-code Flows let you build conversational workflows visually — using prompts, entity extraction, and clear branching — without writing code — unless you explicitly choose to use a Function step for advanced logic. A typical no-code flow:
  1. Ask for information (intent)
  2. Extract structured data (entities)
  3. Route based on what was collected (conditions)
  4. Continue the conversation in the correct branch
  5. End cleanly with an exit flow
You can build most structured interactions using Default steps alone.

Key concepts
  • Step (node): A box in the editor. It represents one moment in the conversation (ask something, confirm something, collect details).
  • Edge: A line between steps. It represents a possible next path.
  • Condition: A label on an edge that explains when that edge should be taken.
  • Entity: A piece of structured information you want to collect (phone number, date, number of passengers).
  • Exit flow: A terminal end point (finish, handoff, stop).

​
Step types

​
Default step (no-code)

Use Default steps for most of your flow. They allow you to:
  • Write natural-language instructions (prompt)
  • Extract entities
  • Branch to other steps using labeled edges
Most booking, verification, and data-collection flows can be built entirely with Default steps. A common pattern:
  • Step 1: Collect an entity (e.g. number of passengers)
  • Step 2: Route to the correct branch (e.g. Individual Booking vs Group Booking)
  • Step 3: Continue collecting relevant details
Keep each step focused on one task.

​
Function step (low-code, still visual)

Use Function steps only when you need more control, such as:
  • Calling an API
  • Applying strict business rules
  • Performing numeric comparisons
  • Writing state changes
If your flow starts to require complex logic, that’s when a Function step becomes appropriate. If you can express the routing clearly using labeled branches, prefer Default steps.

​
Exit flow

Use Exit flows to:
  • End the conversation cleanly
  • Represent a handoff
  • Make terminal paths obvious in the editor
Every flow should end in an Exit flow.

​
How flow logic actually runs

There are two execution models inside flows. Understanding this prevents most confusion.

​
Default steps (LLM-driven)

In a Default step:
  • The LLM evaluates conditions.
  • Condition labels are meaningful.
  • “Required entities” inform the LLM what must be present before a condition can pass.
  • Routing is determined by the model.
If you reference collected entities inside the prompt, you can use rich text /entities. In Conversation Review, you will see system functions such as:
  • builtin_validate_and_save_entities
  • builtin_conditions_met
These represent automatic entity validation and condition evaluation. You do not need to write code for this.

​
Function steps (code-driven)

Function steps behave differently.
  • Conditions are evaluated in your Python code.
  • The condition label on the edge is decorative.
  • You must explicitly move the flow forward.

​
Accessing collected entities in a function

Entities collected earlier in the flow are available as: 
    conv.entities.entity_name.value
Example: 
    email = conv.entities.email.value
    party_size = conv.entities.number_of_passengers.value

​
Moving to another step from a function

A Function step does not automatically transition. You must call: 
    flow.goto_step("step_name", "condition_name")
Example: 
    if party_size > 15:
        flow.goto_step("Group Booking", "large party")
    else:
        flow.goto_step("Individual Booking", "small party")
If you do not call flow.goto_step, the flow will not move.

​
When should you use a Function step?

Use one only when you need:
  • API calls
  • Strict numeric comparisons
  • Business-rule enforcement
  • Custom validation
  • State changes
If routing can be expressed clearly with labeled branches in Default steps, prefer Default steps.

​
Quickstart: build your first flow

This walkthrough builds a simple booking flow:
  • Collect phone number (or fallback to email)
  • Collect booking details
  • Route large parties differently
  • Finish cleanly

​
Step 1 — Create a flow

  1. Go to Flows
  2. Click + Create flow
  3. Name it (example: Make a booking)
Tip: start with a Default step as your entry point.

​
Step 2 — Add your first Default step (entry point)

  1. Add a Default step
  2. Name it Collect contact details
  3. In the Prompt, write something like:
Ask for the caller’s phone number to create or look up the booking. If they don’t want to provide a phone number, ask for an email address instead. Confirm what you captured in one sentence.

​
Step 3 — Add entities to the step

In Collect contact details, add:
  • Phone number
  • Email address (fallback)
This tells the system what structured information to extract and validate. You can mark entities as required if the LLM should not consider a condition satisfied without a valid value. In Function steps, you must enforce this yourself in code.

​
Step 4 — Add routing

After collecting information, add labeled edges such as:
  • phone collected
  • phone missing
  • caller refuses
Keep labels short and explicit. If you later add a step like Collect Number of Passengers, you might branch into:
  • Individual Booking
  • Group Booking
Clear labels make routing easier to understand and maintain.

​
Step 5 — Add a finish/exit step

  1. Add an Exit flow
  2. Name it Booking complete
  3. Connect your success branches to it

​
Write condition labels for humans first

Good labels are:
  • Short
  • Unambiguous
  • Business-focused
Examples:
  • phone collected
  • phone missing
  • party size above 15
  • requires handoff
  • unclear
Avoid vague labels like:
  • valid
  • ok
  • continue
If someone else looks at your flow, they should understand the logic immediately from the labels alone.

​
Entities

Entities are structured values the agent can collect and reuse, such as:
  • Phone number
  • Email
  • Date
  • Time
  • Address
  • Name
  • Number
  • Free text
Mark an entity as required if the LLM should not consider a condition satisfied without a valid value. In Function steps, you must enforce this yourself in code.

​
Validation

Depending on the entity type:
  • Valid values allow the flow to continue.
  • Invalid values can trigger re-asking or fallback routing.
Best practice: If a branch depends on an entity being present, include a clear fallback path for when it isn’t.

​
Glossary

  • Step (node): A unit of conversation in the editor.
  • Edge: A connection between steps.
  • Condition: A label explaining when an edge should be taken.
  • Entity: Typed extracted data (phone, date, number, etc.).
  • Exit flow: A terminal node (finish or handoff).
  • Function step: An optional step used when business logic goes beyond simple branching.