Workflows

A Workflow runs a process you repeat: a new lead comes in, Busabase scores it, tells your CRM, waits a day, checks the lead again, and asks your sales lead to approve the handover. You draw the steps once, and each run goes through them on the server. Nobody has to keep a tab open.

Build a workflow

What each step does

A connection's Outcome decides when it is followed. A run never visits the same step twice, and it stops with an error after 64 steps.

Use earlier results in a condition

A condition can read the step right before it as input, and any earlier step through its reference. Select a step and Use this step in formulas as shows what to write, with a button to copy it:

input.status == 200 && steps.score.score >= 80

&& and || stop as soon as the answer is known, and a value that is missing counts as null, so input.body && input.body.ok is safe. Use brackets for names that are not plain words: fields["follow-up"], items[0].

Does a Wait see the latest data?

Only if you ask it to. Every finished step keeps a snapshot of what it saw, so steps.trigger still shows the record as it was when the run began. To work with current values, put an Action step set to Read the record again after the Wait. It reloads the record, and the next step sees it as input.record.

Change records

An Action step can change your data. Choose what it does from the list:

Record is the run's own record when left empty. It can also be a record ID, or a formula such as =steps.add.createdRecordId to change the record an earlier step created.

Fields to set is a JSON object:

{ "status": "qualified", "score": "=steps.score.score" }

• Use a field's name or slug as the key. Plain values are stored as written.
• A text value that starts with = is a formula over earlier steps. Start with == to store text that itself begins with =.
• A formula that finds nothing fails the step, so a typo never blanks a field or changes the wrong record.

What else to expect:

• The step acts as the person the run acts as, with their access to that Base. If they can edit it, the change applies right away. If they can only propose changes, it goes to the Inbox for review, nothing changes yet, and the step fails and names the change request. With On error set to Continue, the run goes on.
• A change a step applies starts no workflow, including workflows listening to another Base. So a workflow that updates the record it listens to cannot loop, and workflows cannot set each other off. Changes a person makes, or approves later, start workflows as usual.
• If a run deletes its own record, later steps carry on without one, except Read the record again, which fails.

Start a run

By hand. Open the Runs tab, or press the run button in the toolbar. You can pass a Record ID for the trigger to read, and Payload JSON for any extra data. Then press Start run.

When a record changes. Under Configure:

1. Select the Trigger and choose When a record is created or When a record is updated.
2. Pick a Base to limit it to, or leave it on all Bases.
3. Set Execution mode to Event, then save.

Each matching change queues one run, and the scheduler starts it. Event runs act as the person who last saved the workflow in Event mode. If that person leaves the space, those runs fail and say why.

Follow a run

The Runs tab lists the newest runs of this workflow, and Load older runs goes further back. Select a run to see each step in the order it ran, with what it saw and returned. The canvas marks the same steps as done, paused, or failed.

Finished runs are kept for 90 days, then deleted. Runs that have not finished are never deleted.

Approvals

The Approver field decides who can approve or reject:

• Member emails, separated by commas: only those members and space admins can decide. They need read access to the workflow, but not edit access.
• No email (empty, or a name like "Sales lead"): anyone who can edit the workflow can decide. A name is just a label.
• Agents can't decide unless you turn on Let agents decide. See Let agents use workflows.

When a named approver who cannot edit the workflow decides, the run goes to Queued and the scheduler continues it with the access of the person who started it, so an approver's narrower access never changes what the later steps can do.

Cancel a run

Select a run that is Queued, Waiting, or Needs approval, then press Cancel run. A cancelled run cannot be continued, and steps that already ran are not undone.

A run that is executing a step cannot be cancelled until that step finishes, because a request already sent cannot be taken back.

If a bulk import queued more runs than you wanted, Cancel N queued runs at the top of the list stops all the queued ones at once. Runs that are executing a step or paused keep going.

Notifications

You get an in-app notification and an email, and the link opens that run. Whoever is pressing the button at that moment is left out, because they can already see it. Bursts are rolled up: approvals into one message per workflow every 10 minutes, failures into one per hour. The open-source single-user app has no notifications, so check the Runs tab there.

Permissions

Function and Webhook steps send data outside Busabase, and Action steps can change your data, which is why starting a run needs edit access. Anyone who can read the workflow can see each step's data, so don't put secrets in a payload.

Settings

Select nothing on the canvas (or scroll down under Configure) to change these for the whole workflow.

Webhook steps send once and do not retry, because repeating a request is not always safe. Private and internal addresses are refused, including through redirects.

Let agents use workflows

Agents with an API key can use workflows through the REST API, MCP, and the CLI.

Continuing a Wait early and cancelling everything queued stay in the app.

An approval is a person's decision by default. Select the step and turn on Let agents decide to allow an agent. Even then, the key must be write-level and its owner must meet the step's approver rule. The run records which key decided.

A run never outgrows the key that started it. It acts as the key's owner, limited by the key, and the run shows the key's name. Busabase checks the key again each time the run continues, so a run that is waiting stops with a clear error if you revoke the key or it expires, and it can't write if you lower the key's level.

Alerts about a run an agent started go to the key's owner too, because they aren't watching it happen.

Good to know

A run stays Queued for a long time. The workflow may be at its Concurrency, so the run is waiting for a slot. Otherwise check that the scheduler is running. It is built into self-hosted installs (configuration).

"The run was interrupted". The server stopped while a step was running. Busabase marks the run as failed instead of repeating the step, because a half-sent request must not silently run twice. Start it again.

"Could not continue as the person who started this run". That person has left the space or lost access to the workflow. Start a new run, or save the workflow in Event mode yourself so event runs act as you.

Approve and Reject don't appear. The step names other approvers, or you don't have edit access. The run tells you which rule applies.

The demo fails on Function and Webhook steps. The demo has no saved functions and sends no requests. Try those steps in your own space.

A formula fails on a step with a dash in its id. Write steps["step-a1b2c3d4"].status, not steps.step-a1b2c3d4.status. The step's Use this step in formulas as shows the right form.

See also: Node Types · Webhooks & Events · Change Requests