n8n Sub-workflows

When to Use

Use this skill when shared or multi-step logic should become a typed reusable workflow, when an existing workflow is growing difficult to reason about, or when an agent needs a workflow exposed as a tool.

Preserve authentication and authorization boundaries when extracting logic. Do not place credentials in inputs or returned data, declare state-changing behavior explicitly, and ask before running or activating a sub-workflow that sends, writes, deletes, or calls a billable external service.

A sub-workflow is a reusable function. An Execute Workflow Trigger declares typed inputs, the body does the work, and the last node returns the output. A caller invokes it through an Execute Workflow node like any other step.

That framing buys you the things functions buy you everywhere: encapsulation, reuse, testability, replaceability. It's the primary reuse mechanism in n8n, and it's badly underused. Without it, the same logic gets copy-pasted across workflows — then a bug gets fixed in two places, the third copy gets missed, and your "identical" copies quietly drift apart.

This skill is about when to reach for a sub-workflow, how to define its input/output contract so callers (and agents) can actually use it, how to call it correctly (all vs each, blocking vs fire-and-forget), and how to name it so it gets found instead of rebuilt.

The two non-negotiables

Everything else is judgement. These two are not.

1. Search before you build

Before you write logic for a generic problem, check whether a sub-workflow already does it. The community MCP can't filter workflows by tag, so the name is the discovery surface:

n8n_list_workflows()                          # scan the library
n8n_get_workflow({ id: "<candidate>" })       # read its inputs/outputs + body

If something fits, use it and tell the user ("I found Subworkflow: Parse RFC2822 date — using that"). If nothing fits, build it with a discoverable name so the next search finds it. The discovery convention (verb-first prefixes) lives in references/NAMING_AND_DISCOVERY.md.

2. The Execute Workflow Trigger uses "Define Below" with typed fields — not passthrough

The trigger has two input modes. Default to "Define Below" with explicit typed fields. Define Below is the only mode that gives callers a schema to fill — it's what lets an AI agent pass values via $fromAI and what lets structured callers map fields cleanly. Passthrough has no schema, so the trigger can't be wired as a clean agent tool and structured callers have nothing to bind to.

Two exceptions, and only two:

• Binary input. Typed fields are JSON-only. If the sub-workflow must receive an image/file/PDF, you need passthrough so the binary slot flows through.
• Zero inputs. Define Below requires at least one field. A genuinely no-arg operation ("list active credentials", "current count") has nowhere to put an empty schema, so passthrough is the only option.

Outside those two cases, passthrough is a bug. See "Inputs and outputs as a contract" below.

Should this be a sub-workflow?

You're about to write a chunk of logic. Run it through this:

Could this plausibly be needed in another workflow?
  └─ Yes → extract.

Is it a generic concern (auth, retry, parsing, formatting, ID generation)?
  └─ Almost always → extract. These are the canonical reusable sub-workflows.

Is it >5 nodes and conceptually one thing?
  └─ Probably extract, even if reuse isn't certain. It's better isolated.

Is it one HTTP call with no logic around it?
  └─ Don't. A sub-workflow that's just trigger → HTTP → return adds a boundary
     for nothing.

Is it tightly coupled to this one caller's data shape?
  └─ Don't extract yet — fix the data shape first, or you just relocate the coupling.

The reasons to extract go beyond reuse:

• Readability. The caller shows one node ("Parse date") instead of five.
• Testability. Run the sub-workflow alone with pinned input (n8n_test_workflow).
• Replaceability. Swap the implementation without rippling to callers.

A 20-node workflow is fine if it's mostly a linear sequence of Execute Workflow calls and decisions — each node has one purpose, and you inspect a section by opening the sub-workflow it calls. A 20-node workflow of inline transformations is not fine. If yours has 15+ nodes and isn't mostly sub-workflow calls and branches, extract more.

…