Skip to main content
Workflows are in beta. The APIs documented here are stable to build against, but details may evolve before general availability — check the changelog for updates.

​
What are Workflows?

A workflow is a graph of nodes connected by routing rules — each node’s ordered cases decide what runs next. It orchestrates a whole sequence per contact: call them, branch on whether they picked up, retry twice with a 2-minute gap if they didn’t, extract what they said if they did, push the result to your CRM, and follow up on WhatsApp — each contact walking the graph independently. Running the same sequence over many contacts at once uses a campaign — a concept kept deliberately separate from agent batch calling, which places a single call per contact with no graph behind it. Typical uses:
  • Lead qualification — call, score the conversation from extracted fields, route hot leads to an API and cold leads to a WhatsApp nurture message.
  • Collections and reminders — call, capture a promise-to-pay date, record it via your API, schedule the follow-up.
  • Unreachable-contact handling — retry ladders with configurable gaps, then a fallback channel.

​
Why workflows

One definition, every channel

Calls, WhatsApp messages, HTTP calls, waits and retries live in a single graph instead of stitched-together automations across separate tools.

Safe iteration

Drafts are private until published, and publishing again never changes a contact already mid-run on an older version — you can keep editing without risking what’s live.

Built-in retry ladders

Configurable delayed re-attempts live inside the graph itself via the retry node — no separate scheduler or cron job to babysit unreachable contacts.

Full execution replay

Every contact’s path through the graph is recorded node by node with its matched case and outputs, so “why didn’t this fire” has a concrete answer instead of a guess.

​
The object model

Workflow

The named container. Holds one mutable draft and any number of immutable published versions.

Draft and versions

You edit the draft, then publish it as a frozen version. Runs always execute published versions — publishing again never changes anything already running.

Campaign

Runs one published version over a batch of uploaded contacts. Pins its version at creation time.

Execution

One contact’s journey through the graph — node attempts, matched cases, and a terminal outcome.
The lifecycle, end to end:

​
Nodes at a glance

Each node routes onward through ordered cases — condition expressions over the execution’s variables. See Nodes for every node’s configuration, Conditions and variables for the expression language, and AiSensy WhatsApp integration for connecting an AiSensy account to the aisensy_whatsapp node.

​
Authentication and conventions

All workflow endpoints live on the standard API host and authenticate with your Bolna API key:
Three conventions to know:
  • List endpoints paginate with limit/offset and return {items, total, limit, offset}.
  • Errors carry a machine-readable code in detail.code (for example revision_conflict, duplicate_run, invalid_state), with any extra context alongside it.
  • Action endpoints use a :verb suffix — for example POST /workflow-campaigns/{id}:start — with an empty JSON body.

​
Next Steps

Quickstart

Create, publish and run your first workflow, from the dashboard or with curl

Using the editor

A tour of the visual canvas, toolbar and validation

Nodes

Every node type with its configuration and examples

Conditions and variables

The expression language behind branching

Campaigns

Run a workflow over thousands of contacts