> For the complete documentation index, see [llms.txt](https://angoor-ai.gitbook.io/angoor-ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://angoor-ai.gitbook.io/angoor-ai/basics/configuration/flows/routing-components.md).

# Routing components

Routing components decide where a conversation goes next. Each one branches the flow using a different mechanism — a user's button choice, a timer, an AI classification, or a comparison of variables. A routing step produces several output handles, one per branch, and the connector from each handle leads to the path that runs when that branch is taken. You will find these under **Routing** in the step palette.

### Quick Replies

Let's the user choose from a set of predefined options.

When the step runs, it shows the user several buttons or quick-reply options. The flow then branches to the path matching whichever option the user picks — the system compares the user's reply against the button labels and routes accordingly.

<figure><img src="/files/uHFKluBalbMGivXF8nYT" alt=""><figcaption></figcaption></figure>

You add and remove buttons with **Add Quick Reply**. For each button you set a reply prompt (a templated message that supports variables and knowledge base references) and a button type: **TEXT** (the default), **PHONE**, or **URL**. For phone and URL buttons you also supply the call-to-action text or destination. Input variables can be embedded in the prompt body.

Each button becomes one output handle, and each handle connects to a downstream path. The node displays the button's prompt as its handle label, and the system stores a mapping from reply text to handle so it can route the user's selection.

### Wait Time

Pauses the flow for a set duration, then continues automatically.

The step schedules a delayed task and resumes the path once the timer expires. This is how you space out messages or build time-based sequences.

<figure><img src="/files/WgYUcvuTYhZYyA0C5wxq" alt=""><figcaption></figcaption></figure>

You set the wait as hours, minutes, and seconds — each stored as an input variable so the duration can be dynamic. The values are summed into a total wait: hours × 3600, plus minutes × 60, plus seconds.

The step has a single output handle, *When the timer expires*, which fires automatically after the wait elapses. The scheduled task is tracked by an internal task ID.

### Logic Routing

Branches the flow using an AI classifier that reads the conversation and chooses the best-matching branch.

<figure><img src="/files/TiqyPNghe8Gq1j0AGmMF" alt=""><figcaption></figcaption></figure>

For each branch you write a prompt describing its condition — the criterion that should send the conversation down that branch. When the step runs, the classifier weighs the flow context and the user's input against all the branch prompts and selects the one that fits best. This is the routing component to reach for when the decision is semantic rather than a simple comparison.

You add and remove branches with **Add Logic Routing**. Each branch takes a templated logic prompt (supporting variables and knowledge base references) that states its decision criterion. A single classifier evaluates all the branches together and returns the index of the best match.

Each branch becomes one output handle, labeled with its logic prompt, and the flow routes through the matching handle's path. If the classifier fails to reach a decision after three attempts, the error is logged and the path continues without branching.

### Decision Routing

Branches the flow on objective comparisons between variables.

For each branch you define a single condition: a variable, a comparison operator, and a value to check against. The step evaluates the conditions in order and routes through the first one that is true. If none are true, the path simply continues.

<figure><img src="/files/v68Dsi9NPiVSNfrEYp6Z" alt=""><figcaption></figcaption></figure>

You add and remove branches with **Add Decision**. For each branch you choose the variable to check (a flow, execution, or session variable), the comparison operator — **EQUALS**, **NOT\_EQUALS**, **GREATER\_THAN**, **LESS\_THAN**, **CONTAINS**, **STARTS\_WITH**, **ENDS\_WITH**, and others — and the value or variable to compare against. Conditions are evaluated top to bottom and the first match wins. A **Block Path** checkbox, if enabled, stops the flow from continuing to later paths once a decision matches.

example: *user\_type equals premium*. The first branch whose condition is true routes the flow onward. If Block Path is set on the matched branch, the remaining paths in the flow are skipped; otherwise execution continues normally. There is no automatic fallback branch, so handle the no-match case explicitly if you need to.