---
title: 'Execute Workflow'
description: 'Run another of your workflows inline and use its output.'
---
# 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**](/nodes/return) 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.