> 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.md).

# Flows

### Where to start

**Build your first flow.** A flow is the unit of automation in Angoor AI. Open **Flows**, create one, and add a path with a single Text step. That is a working assistant. Everything else is an extension of that idea.

**Connect a channel.** A flow does nothing until it has somewhere to listen. Channel Management connects WhatsApp, Instagram, Slack, email, and voice numbers to your workspace so flows can receive and send messages.

**Add intelligence.** Agents bring large language models into a flow. Tools call your own APIs and GPT-powered logic. Together they turn a scripted responder into something that can reason, look things up, and act.

### The building blocks

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

Everything in Angoor AI is assembled from a small set of concepts. Once these click, the rest of the product is a matter of detail.

A **Flow** is the container for a single piece of automation logic. It holds the entry points that start it and the paths that run when it starts. A flow can be triggered by an incoming message, a scheduled event, or a system event such as a new session opening.

An **Entry Point** is a starting gate. Each one is tied to a specific trigger — *when a user sends a message*, *when a new session starts*, and so on. A flow can have several entry points, so the same flow can respond differently depending on what set it off.

A **Path** is an ordered lane of steps. When an entry point fires, execution enters the path connected to it and runs the steps top to bottom. Paths are where your logic actually lives.

A **Step** (called a Path Component internally) is one action or decision inside a path. A step might send a message, branch the conversation, run an AI agent, call an API, or perform one of ninety built-in operations. Steps run one after another in the order you place them.

**Handles and Connectors** wire everything together. A handle is an attachment point on a step — think of it as an input or output port. A connector is the wire between two handles, and it defines which step runs next. Routing steps produce several output handles, one per branch, which is how a conversation forks down different paths.

### The six kinds of step

Every step you can add falls into one of six categories. The category tells you what kind of work the step does.

**Content** steps send something to the user — a text message, an image, a video, a document, a WhatsApp template, an email. See Content components.

**Routing** steps decide where the conversation goes next. They evaluate a condition or a user reply and branch to different paths. See Routing components.

**Agent** steps run an AI agent: a large language model with a configured prompt, optional knowledge sources, and a form for collecting input. See Agents, Tools & Sub-Flows.

**Tool** steps call a tool — either a GPT-powered tool or an API tool that makes HTTP requests to an external service. See Agents, Tools & Sub-Flows.

**Action** steps run a discrete piece of backend logic: set a variable, create a ticket, query Shopify, generate a payment link, transcribe audio, and dozens more. There are ninety of them. See Actions.

**Flow** steps invoke another flow as a sub-flow, so you can build reusable logic once and call it from anywhere. See Agents, Tools & Sub-Flows.

### How a flow runs

At runtime, every flow follows the same sequence.

A **trigger** fires — someone sends a message, a scheduled task comes due, or a session is created. The **entry point** matching that trigger activates. Its connectors route execution into the first **path**. The **steps** in that path then run in order: each one takes its inputs, does its work, and writes its outputs to flow variables that later steps can read.

When a step is a routing step, it evaluates its branches and the connectors redirect execution down whichever path matches. The flow continues until there are no more connectors to follow, or until a step explicitly stops it. Then it either completes or, in the case of a loop, runs again.

### How to read the component pages

Each component in this documentation is described the same way, so you always know where to look.

The **display name** is what you see in the flow builder's step palette. The **category** is one of the six above.&#x20;

**What it does** explains the component's job in plain terms. **Inputs** are the values you bind in the side panel when you configure the step — each lists its name, its type, whether it is required, and what it is for.&#x20;

**Outputs** are the results the step writes back to flow variables for downstream steps to use. **Notes** cover the caveats, prerequisites, and best practices worth knowing before you rely on a component.

A note on types: an input or output marked *variable* holds a value passed through the flow. Types like *Entity*, *Form*, *Team*, *UserGroup*, *Tool*, *ShopifyLogin*, and similar refer to objects you have already set up elsewhere in your workspace, which you select rather than type.

**Navigation:** Configuration → Flows → Edit Flow.