Composition
In the admin: Workflows › a Workflow › a step
Composition steps put a run together from larger pieces: another workflow, a pause, or a list processed in chunks.
| Step | Does | Outputs | Result, as {{step.data}} |
|---|---|---|---|
| Execute another workflow | Run another workflow and wait for it | Success, Error | { run, status, result } |
| Wait | Pause for a fixed time | Success, Error | { waitedSeconds } |
| Process in batches | Run a block once per chunk of a list | Batch, Done, Error | each batch's final data |
Execute another workflow
| Field | |
|---|---|
| Workflow | Required. Another workflow whose trigger is Manual or Schedule |
| Input | Passed as the called workflow's trigger data, its {{start.data}}, with {{…}} |
The called workflow runs synchronously as a run of its own, of its live version, with its own steps and history; the calling step waits for it. It must be published and enabled. Use it to share a process between workflows, such as one email-the-dispatcher workflow several others call.
Who the called run acts as depends on its trigger:
| Called workflow | Executor | Check |
|---|---|---|
| Manual | its Execute as if set, else the calling run's executor | the calling run's executor needs the called workflow's invoke grant, otherwise ACTION_DENIED. Its input form, if any, checks the input |
| Schedule | its Execute as | none. It receives its schedule object, not the step's input |
The result is the called run's id, status and result: {{notify.data.result}}. If the called run fails, this step fails with WORKFLOW_EXECUTION_FAILED and its message.
Loops are refused before anything runs: a workflow can't call itself, directly or through others, and a chain can hold at most workflows.max_chain_depth workflows (8 by default). The same chain counts the workflows started by each other's database events.
A workflow called this way lists its callers under Called by in its editor's header. Prefer this step to an HTTP request to the workflow's own URL, which would lose both.
Wait
| Field | |
|---|---|
| Wait time | Required. Seconds to pause before the next step, 60 by default |
The run pauses in the server and continues after the wait. The pause counts toward the run's maximum duration (workflows.max_run_duration_ms, 15 minutes by default): a longer wait fails at once with WORKFLOW_LIMIT_EXCEEDED. If TotalBase restarts during a wait, the run is interrupted, not resumed.
Wait is for short pauses, such as giving another system time to process a request before reading its answer. It can't wait for a signal or for days.
Process in batches
| Field | |
|---|---|
| Batch size | How many items per batch, 50 by default |
| Source | Must resolve to a JSON array |
It works like For each item, but the body runs once per batch: connect Batch to the first step of the body and Done to what follows. Inside the body, {{item}} is the current batch, a list of up to Batch size items.
Batches run one after another; the first failed batch stops the loop, and batches already done keep their effects. The source can hold at most workflows.max_iteration_items items (500 by default). A loop can't contain another loop.
Batches suit steps that take a list, such as Create records. Acme's Maintenance plan reads the equipment due for service, shapes one work order per unit in an Execute JavaScript step, and creates them 50 at a time:
| Step | Configuration |
|---|---|
| Process in batches | Source {{build_orders.data}}, Batch size 50 |
| Create records, on Batch | Resource work_orders, Records {{item}} |
Each batch is its own transaction: if the third batch fails, the first two are created.