> 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/flow-builder-and-settings.md). # Flow Builder & Settings A flow is the unit of automation in Angoor AI. It listens for an event, runs through a series of steps, and responds. This page covers the flow editor, the sub-flows every flow contains, the settings that govern a flow's behavior, and the per-step options available on any component. ### The flow editor
You build a flow on a canvas. The left sidebar holds your workspace navigation — Agents, Flows, Channel Management, Forms, Entities, Tools, Integrations, and Widget. The canvas itself is where you lay out paths and steps. At the top of the canvas, a dropdown lets you switch between the flow's sub-flows (described below). The default selection is **Main Flow**. To the top right, **Settings** opens the flow's configuration and **Test** runs the flow in a sandbox so you can try it before it goes live. Along the bottom of the canvas are zoom controls, a fit-to-screen button, and **Add Path**, which drops a new path onto the canvas. A path begins life empty, showing a single **Add Step** button and a warning icon that clears once the path has at least one step. Use **Save** in the top right to commit your changes, or **Discard** to abandon them. Connectors you draw while editing are not active until you save — saving is what links them into the flow. ### Sub-flows Every flow comes with six built-in sub-flows, each a separate entry point that fires on a different event and each with its own canvas you can switch to from the dropdown at the top of the editor. This lets a single flow handle the whole lifecycle of a conversation rather than just incoming messages. You are not limited to these six, though. You can also create your own sub-flows to build gated logic or loops within the flow.
**Main Flow** runs every time a user sends a message. This is where most of your logic lives. **On Setup** runs once, when a new conversation session is created — for example, the first time a user makes contact. Use it to greet, to set up context, or to seed variables. **On Error** runs when the flow fails or a path errors out. Use it to recover gracefully, notify a human, or send a fallback message. **Pre Flow** runs before the Main Flow, on every message. It is the right place for guards and gating — checks that should happen before your main logic, such as blocking a closed session or controlling who is allowed through. **Post Flow** runs after a session is closed. Use it for cleanup, follow-up, or analytics that should happen once the conversation is over. **On Control** runs when an external system or human agent takes control of the session. Use it to hand off cleanly. Each sub-flow receives its own trigger payload when it fires, carrying the platform, the channel, the user's context, the session, and the incoming message. ### Flow settings The Settings panel governs how the flow behaves as a whole.
**Flow name** identifies the flow in your workspace. **Description** and **Tags** are optional and help you organize flows as your library grows. **Select Form** is where you define environmental values you want to use during the flow's execution without persisting them. These values are available to the flow while it runs but are not saved afterward. **Add Channels** binds the flow to the channels it should listen on. This is what connects an entry point to a real WhatsApp number, Instagram account, or Slack workspace. **Add User Groups** scopes the flow to specific groups of users. **Expiration Time** sets how long a session stays open before it expires, configured in hours and minutes. The default is **Never**, meaning sessions do not expire on a timer. **Flow Type** is one of two modes. * **Agentic** flows are conversational and AI-driven; they reason about context and adapt. * **Action** flows are deterministic and run a fixed sequence of steps. Choose Agentic when the assistant needs to hold a conversation, Action when you want predictable, scripted behavior. **Test Mode** lets you run the flow against a restricted set of identifiers without affecting real users. Enter the identifiers allowed to trigger the flow in test mode in the **Test Mode Identifiers** field. **Note** : Test Mode overrides everything, including all channel management hierarchies — when it is active, the configured identifiers take precedence over your normal channel routing. Note: **Ignore Past Sessions** starts each test fresh rather than resuming history. **Restrict Send If Multiple Inputs** handles the case where a user sends a new message before the flow has finished responding to their previous one. When enabled, the flow makes the agent abandon its in-progress response and generate a fresh one based on the user's latest input, so the reply always reflects what the user most recently said rather than a now-outdated answer. ### Paths A path is an ordered lane of steps that runs when an entry point routes to it. You add a path with **Add Path**, give it a name, and fill it with steps.
Steps run top to bottom. Click any step to edit it in the side panel. The panel header shows the path name and reminds you that steps run in order; below it, the **Steps** list reflects the sequence you have built. A path connects to its entry point — and to other paths — through connectors drawn between handles. Routing steps create the forks: each branch of a routing step is its own output handle, and the connector from that handle decides which path runs when that branch is taken. ### Per-step settings Every step, regardless of category, exposes a set of additional settings in its side panel. These control how the step runs rather than what it does.
**Retry on Error** re-runs the step if it fails, which is useful for steps that depend on an external service that may be briefly unavailable. **Run Once Per Session** ensures the step runs only the first time it is reached within a session, no matter how many times the path is re-entered. Use it for one-time setup, like a welcome message you never want to repeat. **Run Once Per Execution** ensures the step runs only once within a single flow execution, even if the path loops. **Run Post Async** runs the step asynchronously after the rest of the path, rather than blocking execution while it completes. Use it for work whose result the conversation does not need to wait on — logging, notifications, or background updates. This is especially valuable for real-time voice agents: the agent can respond to the user immediately instead of waiting on the step to finish, keeping the conversation natural and free of pauses. ### Adding a step Click **Add Step** on any path to open the step palette. The palette is organized by the six categories — **All**, **Content**, **Routing**, **Agents**, **Tools**, and **Actions** — with a search box at the top. Pick a category to narrow the list, or search by name. Selecting a component adds it to the path, where you then configure its inputs in the side panel.