Cross-site automation

Because a workspace holds one connection per integration, a workspace maps to one site. Cross-site automation is what lets a workflow in one workspace reach another — by calling a sub-automation that lives there.

It's available on plans that include cross-site automation.

When you'd want it

Agencies. A routine that belongs to the agency — logging client events, notifying an internal channel, updating a central tracker — called from workflows on each client site. Written once, not copied per client.

Businesses running several sites. The same shared step invoked from every site, so a change lands in one place instead of five.

The pattern is the same either way: the site-specific work stays on the site, and the shared work lives in one workspace that the others call into.

How it works

You add a sub-automation call step and select an automation in another workspace. When a run reaches that step:

1. The calling step goes to sleep.
2. A separate run starts for the target automation, in its own workspace, using the connections there.
3. When it finishes, the calling run wakes and continues at the next step.

It's a genuine call and return, so steps after the call can rely on the sub-automation having completed.

What you need for it to work

A plan that includes cross-site automation. Selecting a target in another workspace is refused otherwise, with a message saying your plan doesn't allow calling sub-automations from other workspaces. Calling within a single workspace works on every plan.

Access to both workspaces. The picker only offers automations from workspaces in the same organisation that you personally are a member of. Someone else's workspace never becomes reachable just because it shares your organisation.

A start node on the target. An automation isn't callable until it has a sub-automation start node — that's what marks it as an entry point.

The target must be active. Calling an inactive automation stops the run with an error.

No circular calls. Nodest walks the whole chain and refuses a target that would eventually call back into the automation you're editing.

Where to look when something goes wrong

The two runs are separate records, linked by the call.

If the calling run shows the call step sleeping and nothing after it, the answer is in the child run — and that run belongs to the workspace it executed in, not the one that called it. So debugging a cross-site call usually means switching workspaces.

If the child run fails, the calling step fails too, and the steps after it don't execute.

A worked example

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

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 tracker
3. Action — post to the internal channel

Three sites, one shared routine. The tracker and internal channel are connected once, in the agency workspace, and no client workspace needs those credentials at all.

That last point is worth noting: the shared routine runs with the agency's connections, so client workspaces never gain access to internal tools.