Execute Workflow

Runs another of your workflows as a step inside this one and hands its result back to the parent. Use it to factor shared logic into a reusable sub-workflow and call it from several places — the workflow equivalent of a function call.

When to use

• You have a sequence of steps you repeat across several workflows (e.g. "enrich a player profile", "post a formatted alert") — build it once and call it everywhere.
• You want to keep a large workflow readable by extracting a chunk into a named sub-workflow.

Configuration

Field	Required	What it does
workflowId	Yes	The workflow to run, chosen from a picker of your own workflows.
inputField	No	The data passed to the sub-workflow. Blank = the upstream node's output.

The sub-workflow runs as you — same account, same connections. Its trigger's event data is the input you pass here.

Getting a clean result back

Add a Return Value node inside the sub-workflow to designate exactly what it hands back. Whatever you set there becomes this node's output:

Sub-workflow:  [Trigger] → [work…] → [Return Value: { "risk": "high", "score": 82 }]
Parent:        … [Execute Workflow] → [If {{execute_workflow.output.risk}} == "high"]

Without a Return node, output falls back to the sub-run's raw execution record — usable, but not a clean designated value. Use Return whenever the parent needs a specific result.

What it outputs

{
  workflowId: "wf_…",
  output: <the sub-workflow's Return value, or its raw execution result if none>,
  success: true
}

Downstream nodes reference {{execute_workflow.output.<field>}}.

Safety limits

These are enforced automatically — you don't configure them:

• Same tenant only. You can only call your own workflows.
• Bounded depth. A chain of sub-workflows can nest a few levels deep, then further calls are refused — so a runaway chain can't spiral.
• No cycles. A workflow can't call itself, directly or through a chain that loops back to it. The attempt is rejected rather than looping forever.

Gotchas

• Billing. The sub-workflow's own nodes are metered as they run — the Execute Workflow node itself adds no separate charge, so you're billed once, not twice.
• It runs synchronously. The parent waits for the sub-workflow to finish before continuing. A slow sub-workflow slows the parent.
• Pick the input deliberately. The sub-workflow only sees what you pass in inputField (or the upstream output) — it does not inherit the parent's full context.