> ## Documentation Index
> Fetch the complete documentation index at: https://docs.runflow.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Automations

> Build event-driven processes with reusable blocks, persistent execution history, and dedicated workers

Automations run a defined sequence of actions when an HTTP request, a channel event, or a schedule arrives. Use them to send notifications, synchronize systems, process delivery updates, enrich records, or prepare context before handing a conversation to an agent.

You configure **sections**, **entry conditions**, and **steps** in the Portal or through MCP. The platform admits the event, persists the execution, and processes it on dedicated automation workers. A normal automation does not start an agent runtime for each event. It calls a model only when you add an LLM block, and calls an agent only when you add an Agent block or route a separate conversation event to one.

> [!NOTE]
>
> Automations must be enabled for your workspace. If the module or its MCP tools are missing, ask your workspace administrator about availability. The same product model and block contracts apply across workspaces.

## Choose the right execution model

| Capability | Use it when |
| - | - |
| **Automation** | The sequence is explicit: validate input, look up data, branch, call an integration, persist context, send a message. Optional LLM steps handle bounded language tasks. |
| **Agent** | A conversation needs reasoning, tools, context, and multiple user turns. |
| **SDK workflow** | You want a TypeScript orchestration pipeline inside your application or agent, using the SDK `flow()` API. |

Automations and [SDK workflows](https://docs.runflow.ai/core-concepts/workflows.md) are separate interfaces. Their definitions, variable syntax, execution lifecycles, and deployment mechanisms are not interchangeable.

## How a run works

```mermaid theme={null}
flowchart LR
  A[Webhook, channel event, or schedule] --> B[Admission and section selection]
  B --> C[Persistent run and automation queue]
  C --> D[Automation workers]
  D --> E[Steps: integrations, data, messaging, AI]
  E --> F[Run and step results]
```

The automation queue is separate from the queue used to execute agents. Worker capacity can scale independently. External API limits, messaging-provider limits, and configured workspace rate limits still apply; adding workers does not bypass them.

## Understand the building blocks

* **Automation:** a named, versioned definition owned by a workspace, with a status and execution history.
* **Section:** an entry point and its ordered list of steps. One automation can contain several sections, such as a webhook and a schedule.
* **Entry:** the event source: webhook, channel event, or cron schedule.
* **Entry conditions:** rules that decide whether a section matches an incoming event. For webhook/channel delivery, the first matching section for that entry is selected; sections are not automatic fan-out branches.
* **Step:** a named action with a stable `key`, inputs, optional conditions, and an error policy.
* **Run:** a persisted execution of one section. Step records show results, skips, errors, and timing.
* **Trigger binding:** an optional route from an existing HTTP trigger to an automation, preserving the caller's URL.

## What you can build

| Pattern | Typical blocks |
| - | - |
| Notification delivery | Transform → If → Connector → Send message → KV |
| Delivery-status tracking | Channel status → KV lookup → If → Connector or HTTP |
| Record enrichment | Webhook → Parallel lookups → Transform → Connector |
| Scheduled reconciliation | Schedule → Connector → For each → If → HTTP |
| Document triage | Knowledge search → LLM → If → Connector or Agent |
| Conversation preparation | Read agent memory → Transform → Write agent memory; subsequent user messages go to the agent |

These are patterns, not built-in business rules. Eligibility, campaign identity, consent, deduplication, and callback contracts belong to your integration. Keep those rules versioned and test them whenever either the automation or the receiving agent changes.

## Lifecycle

New automations start as `DRAFT`. Activate them to accept live events and schedules; pause them to stop new admissions. Pausing is not cancellation of work already accepted by the queue.

Editing a definition changes its version. An accepted run is associated with its accepted definition version; new requests use the active definition. Editing an **ACTIVE** automation can therefore change live behavior immediately. Review and test before saving changes to an active flow.

> [card] [Build your first automation](https://docs.runflow.ai/automations/quickstart.md)
>
> Create and test a small webhook flow.

> [card] [Block reference](https://docs.runflow.ai/automations/blocks.md)
>
> Understand every action, input, output, and constraint.

> [card] [Data and routing](https://docs.runflow.ai/automations/data-and-routing.md)
>
> Use variables, conditions, triggers, and channel events.

> [card] [Testing and operations](https://docs.runflow.ai/automations/testing-and-operations.md)
>
> Understand simulation, retries, limits, and diagnostics.

> [card] [Manage with MCP](https://docs.runflow.ai/automations/mcp.md)
>
> Create, inspect, update, and operate automations.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.