A Callable invoked from another automation behaves like a reusable function — the parent automation passes inputs, the Callable runs its steps, and the parent either waits for the result or moves on immediately. Use this pattern to share logic across automations without copying steps, so a single change to the Callable applies everywhere it is called.
Overview
When a parent automation reaches a node that invokes a Callable, it hands off the defined inputs and triggers the Callable's run. The parent then either waits (synchronous) or continues immediately (asynchronous), depending on how the invocation is configured. Because the Callable's logic is centralized, updates to it take effect for every automation that calls it.
How Invocation Works
Inside a parent automation, you add a Callable invocation node and select the Callable to run. You map the parent's data fields to the Callable's defined inputs. The platform then starts a run of the Callable, passing those values in.
The Callable runs its own steps independently — it has its own execution context. When it finishes, it produces its defined outputs. What happens next depends on whether the invocation is synchronous or asynchronous.
Synchronous Invocation
In synchronous mode, the parent waits for the Callable to complete before it continues. When the Callable finishes, the parent receives its full outputs and can reference them in subsequent steps — exactly as if it had run those steps itself.
Error handling is coupled: if the Callable fails, that error propagates to the parent. The parent can catch and handle it. Use synchronous invocation when:
The parent needs the Callable's output values before it can proceed.
The parent must know whether the Callable succeeded before taking the next action.
You want a failure in the Callable to surface in the parent's error handling.
Asynchronous Invocation
In asynchronous mode, the parent fires the Callable and moves on immediately. The parent receives only a simple acknowledgement — a success flag confirming the Callable was started — not the Callable's real outputs. The Callable then runs independently in its own execution context.
Error handling is decoupled: if the Callable fails, that failure stays isolated — it does not affect the parent. Use asynchronous invocation when:
The parent does not need the Callable's outputs to continue.
The work is fire-and-forget: notifications, background processing, or side effects the parent does not need to track.
You want the parent to stay unaffected by failures in the Callable.
Pick the right mode for the relationship: If the parent's correctness depends on what the Callable does, use synchronous. If the Callable is a side effect the parent can safely ignore, use asynchronous.
Run Context
When configured to run in user context, the Callable executes as the user who triggered the parent automation. This keeps access-control checks accurate when the Callable reads or writes data scoped per user. Without user context, the Callable runs as a generic service identity and behaves identically regardless of who triggered the parent.
Notes
Keep the following in mind when invoking a Callable from another automation.
Choose synchronous when the parent needs the result or must confirm success before continuing. Choose asynchronous for fire-and-forget work where the parent should keep moving and not be affected by failures.
In synchronous mode, a Callable failure propagates to the parent — handle it in the parent's error path.
In asynchronous mode, the parent receives only an acknowledgement flag, not the Callable's outputs. Do not attempt to read Callable outputs after an async invocation.
Enable user context when the Callable accesses data whose permissions are scoped to the triggering user.
Multiple automations can invoke the same Callable independently. Updates to the Callable apply immediately to all of them.
Test the Callable in isolation first to confirm its inputs, outputs, and error behavior, then wire it into the parent automation and test the combined flow end-to-end.