Sub-automations

A sub-automation is an automation that another automation calls as a single step. The calling run pauses, the sub-automation runs, and control returns so the remaining steps continue.

The important case is across workspaces. Because each workspace holds its own connections — and therefore its own site — calling a sub-automation in another workspace is how one workflow reaches a second site. That's cross-site automation.

What can I do with it?

Within one workspace, it's reuse: build a sequence once and call it from several automations, so a change lands in one place.

Across workspaces, it's reach: an automation on one site can run steps against another. An agency can have a workflow on a client site call a routine in the agency's own workspace; a business running several sites can centralise a step instead of copying it into each one.

What do I need for it to work?

Three conditions, all enforced when you select the target:

1. The target has a sub-automation start node. An automation isn't callable until it has one — that node is what marks it as an entry point.
2. The target is active. Calling an inactive automation stops the run with an error.
3. No circular dependency. Nodest walks the whole call chain and refuses a target that would eventually call back into the automation you're editing.

Which automations can I choose from?

By default, the ones in your current workspace.

If your plan includes cross-site automation, the list also includes automations from other workspaces in the same organisation — limited to workspaces you personally have access to. Someone else's workspace never becomes reachable just because it belongs to the same organisation.

Cross-site automation is available on higher plans. Calling within a single workspace works on every plan.

What happens when the plan doesn't allow it?

Selecting a target in another workspace is refused with a message saying your plan doesn't allow calling sub-automations from other workspaces. Same-workspace calls are unaffected.

Which version of the sub-automation runs?

The latest version of the target, at the moment the call happens — not a copy taken when you built the calling automation. Publishing a change to a shared sub-automation therefore applies to everything that calls it, which is the point.

What happens while it runs?

The call node waits. The parent run sleeps until the sub-automation finishes, then resumes at the step after the call — a genuine call-and-return, not fire-and-forget. Steps after the call can rely on the sub-automation having completed.

What if it fails?

A failure inside the sub-automation stops the run, and the steps after the call node don't execute — the same as any other failing step.

A worked example

An agency running three client sites, each in its own workspace, plus an internal workspace:

On each client site

1. Trigger — Order placed in WooCommerce
2. Filter — only orders above the threshold
3. Sub-automation call → Log client event

In the agency workspace — Log client event

1. Sub-automation start
2. Action — create a record in the agency's tracking tool
3. Action — post to the internal channel

Three sites, one shared routine. Change the internal logging once and every site follows.