Skip to main content
Entities are structured values the agent can collect and reuse during a flow. Each entity has a type that determines what validation is applied. Entity names must be unique across all entities in your project. Mark an entity as required on a condition if the LLM should not consider that condition satisfied without a valid value. In Function steps, you must enforce this yourself in code.

​
Entity types and configuration

Open-ended responses with no validation. Use when you need to capture unstructured input like comments or descriptions.
Numeric values. Configure:
  • Decimal — toggle to accept decimal values (float) or restrict to integers
  • Range — optionally set a minimum and maximum value (up to 1,000,000)
Any mix of letters and numbers. Useful for booking references, confirmation codes, or postal codes. Configure:
  • Validation type — choose a built-in preset or custom regex:
    • Zip code — US zip code format (e.g. 12345 or 12345-6789)
    • Postal code — UK postal code format
    • Custom — your own regular expression
Telephone numbers. Configure:
  • Country codes — restrict to specific countries (26 supported, including US, CA, GB, AU, DE, FR, and others)
Calendar dates. No additional configuration.
Clock times. Configure:
  • Time range — set a start and end time to restrict valid values
Selection from a predefined list. Configure:
  • Options — the accepted values the caller can choose from
Personal names (first name, last name, or both). No additional configuration.
Street addresses or locations. No additional configuration.

​
Entity visibility within a step

Entities extracted in a step are immediately available within that same step. You can:
  • Reference entities in the prompt using {{entity:entity_name}} — the system resolves the value at runtime, so a prompt can adapt its wording based on what the caller just provided.
  • Use entities in redirect conditions — mark an entity as a required entity on a condition so the LLM will not activate that path until the entity has been collected and validated.
In short, extraction and evaluation happen within the same step execution — you do not need a separate step to use an entity you just collected.
Entity extraction is a flow-only feature. Managed Topics do not support entity extraction directly. If you need to collect structured data when a topic is matched, use the topic’s action to trigger a flow and configure entity extraction in that flow’s steps.

​
Validation and retries

Depending on the entity type:
  • Valid values allow the flow to continue.
  • Invalid values trigger re-asking or fallback routing.
Because there is no automatic cap on retries, always design your flow with a fallback condition (e.g. “caller unable to provide”) so the conversation can exit the step gracefully if collection stalls.
If a branch depends on an entity being present, always include a clear fallback path for when it is not collected or fails validation.

​
Accessing entities in code

Entities collected earlier in a flow are available in Function steps via conv.entities.entity_name.value. Entity values are always strings — cast to int() or float() before numeric comparisons. See no-code flows — accessing entities in a function for examples.

No-code flows overview

Step types, routing logic, and canvas controls.

Quickstart

Build your first no-code flow step by step.

Advanced steps

ASR biasing, DTMF, and rich text references.
Last modified on April 15, 2026