Can a Callable invoke another Callable?

Yes. A Callable is itself an automation and can invoke other Callables as steps, up to whatever nesting depth your platform supports. This allows you to compose complex shared logic from smaller, well-defined building blocks.

What is the difference between a Callable and a regular automation?

A regular automation triggers automatically on an event (a webhook, a schedule, a platform event). A Callable waits to be explicitly invoked by another automation or an API client. It has a defined input/output contract; regular automations do not need one.

Can I call the same Callable both synchronously and asynchronously from different callers?

Yes. The sync/async choice is made by the caller at invocation time, not by the Callable itself. Different callers can invoke the same Callable with different modes.

A Callable is a reusable automation that other automations — or an external system via API — can invoke like a function. You define its inputs and outputs once, then call it from many places instead of copying the same steps everywhere. Use Callables to factor out shared logic so it lives in one place and every caller stays in sync.

Overview

Where a standard automation triggers on an event, a Callable waits to be invoked. It has a defined input signature and produces outputs that callers can use. A Callable can be invoked synchronously (the caller waits for the result) or asynchronously (the caller fires and moves on). It can also run in the calling user's security context when access-controlled data is involved

What Is a Callable?

A Callable is an automation built to be invoked rather than to trigger on its own. You give it a set of named inputs and a set of named outputs, then build the steps that process those inputs and produce those outputs. Any caller — another automation or an API client — passes in the inputs and receives the outputs in return.

Common uses include shared sub-routines such as "create a customer record", "score a lead", or "send the standard onboarding sequence." Because the logic lives in one Callable, a fix or improvement there applies everywhere it is used without touching each caller individually.

How a Callable Can Be Invoked

A Callable can be triggered in two ways:

From another automation — a parent automation reaches a node that invokes the Callable, passing inputs and (if synchronous) receiving its outputs before continuing. This is the most common pattern for sharing logic between automations.
Via API — the Callable is exposed as an HTTP endpoint that external systems can call directly. This lets any system that can make an HTTP request run the automation and receive a result.

Synchronous vs Asynchronous

Every invocation of a Callable is either synchronous or asynchronous — a choice the caller makes at the time of invocation:

Synchronous — the caller waits for the Callable to complete and receives its full outputs. If the Callable fails, that error propagates to the caller. Use this when the caller needs the result before it can continue.
Asynchronous — the caller fires the Callable and moves on immediately, receiving only a simple acknowledgement (a success flag), not the Callable's real outputs. The Callable runs independently, and its errors stay isolated — a failure does not affect the caller. Use this for fire-and-forget work such as notifications or background processing.

Run Context

A Callable can run in the calling user's context when configured to do so. In user context, the Callable's actions are performed and permission-checked as that specific user rather than as a generic service identity. This matters when the Callable reads or writes access-controlled data — running in user context keeps those permission checks correct.

If you want consistent, centralized behavior regardless of who triggered the invocation, configure the Callable to run without user context. It will then behave identically for every caller.

Notes

Keep the following in mind when designing and using Callables.

Define clear, named inputs and outputs. Callers depend on this interface — changing it without updating callers will break them.
Use Callables to centralize shared logic. A fix applied to the Callable propagates to all callers automatically.
Choose synchronous when the caller needs the result or must know the Callable succeeded before continuing; choose asynchronous for fire-and-forget work where the parent should not wait or be affected by failures.
Enable user context when the Callable accesses data whose permissions are scoped per user. Omit it for centralized, service-level operations.
A Callable can be invoked from another automation or via API — both invocation paths support synchronous and asynchronous modes.

Test each Callable in isolation before wiring callers to it. Confirm that inputs, outputs, and error paths all behave as expected, then integrate with the calling automation or API client.