Skip to main content
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.
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

Automations and SDK workflows are separate interfaces. Their definitions, variable syntax, execution lifecycles, and deployment mechanisms are not interchangeable.

​
How a run works

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

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.

Build your first automation

Create and test a small webhook flow.

Block reference

Understand every action, input, output, and constraint.

Data and routing

Use variables, conditions, triggers, and channel events.

Testing and operations

Understand simulation, retries, limits, and diagnostics.

Manage with MCP

Create, inspect, update, and operate automations.