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


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://angoor-ai.gitbook.io/angoor-ai/basics/configuration/flows.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.