Build reusable sub-workflows in n8n with typed contracts

This skill treats an n8n sub-workflow as a reusable function: an Execute Workflow Trigger declares typed inputs, the body does the work, and the last node returns output, with a caller invoking it through an Execute Workflow node like any other step - buying encapsulation, reuse, testability, and replaceability, and correcting the common failure mode where copy-pasted logic drifts apart across workflows because a bug gets fixed in only some copies. Two rules are non-negotiable rather than judgment calls. First, search before you build: since the community MCP can't filter workflows by tag, the workflow name is the whole discovery surface, so n8n_list_workflows() plus n8n_get_workflow() on a candidate must be checked before writing generic logic, and anything built new needs a discoverable, verb-first name so the next search finds it instead of duplicating it. Second, the Execute Workflow Trigger should default to "Define Below" with explicit typed fields rather than passthrough, since Define Below is the only mode that gives callers (including an AI agent via $fromAI) an actual schema to fill; the only two legitimate exceptions are binary input (typed fields are JSON-only, so a file/image/PDF needs passthrough to carry the binary slot) and a genuinely zero-argument operation (Define Below requires at least one field). Deciding whether to extract logic into a sub-workflow at all runs through a short decision tree: extract if it could plausibly be needed elsewhere, extract almost always for a generic concern (auth, retry, parsing, formatting, ID generation), extract if it's more than five nodes and conceptually one thing, but don't extract a single HTTP call with no surrounding logic, and don't extract logic that's still tightly coupled to one caller's specific data shape - fix the data shape first or the coupling just relocates. A 20-node workflow built mostly from Execute Workflow calls and branching decisions is fine to read; a 20-node workflow of inline transformations is not, and is a signal to extract more. Sub-workflows come in two deliberate flavors: stateless ones (input in, output out, no side-effecting I/O - parsing a date, computing MRR, formatting an invoice) as the default for pure logic, and stateful ones that read or write external state behind a clean contract (a repository pattern: "get customer by id," "write billing record," "notify on-call") so callers think in domain terms rather than SQL and the underlying store can be swapped without touching any caller. The failure mode to avoid is accidental state - a sub-workflow named and described as pure that quietly writes to a log table, ambushing every caller who assumed it was safe to retry; the fix is either making the side effect part of the documented contract or moving it out entirely. Inputs and outputs together form the sub-workflow's actual API and should be treated as one: each declared input gets a deliberate type (string/number/boolean/array/object) that an agent or human caller relies on; the workflow's description documents field names, types, purpose, and searchable keywords, since that's what both callers and n8n_list_workflows match against; returns should be consistent, natural shapes (arrays as arrays, dates as ISO strings) regardless of how the data happened to be stored internally - the common slip is stringifying a freshly computed value to match a cached, stringified path, when the right instinct is parsing the cached path so both return the same natural shape; expected failures (a parse error, a not-found) should return { ok: false, error } so callers can branch without a separate error output, reserving actual throws for genuinely unexpected failures; and the contract is frozen once it has callers - adding optional fields is safe, but renaming or removing one is dangerous because n8n doesn't error on an unrecognized field, it just silently resolves to undefined, so any field change requires enumerating every caller and migrating them in the same change. A final Set/Edit Fields node named Return or Return <thing> is the one legitimate exception to the usual "don't add a trailing Set node" rule, since it makes a sub-workflow's whole return contract visible to a reader in one node. On the calling side, two Execute Workflow node settings matter: mode (all, the default, runs the sub-workflow once against all N items together; each runs it N times, once per item) only matters when the body assumes it sees exactly one item, in which case mode: each should be preferred over an internal Loop Over Items node; and waitForSubWorkflow (default true, blocking) can be set false for fire-and-forget dispatch, and mode: each plus waitForSubWorkflow: false together are the only way n8n offers genuinely concurrent sub-workflow execution, usually paired with a Data Table the sub-workflow updates as a separate completion-tracking mechanism. When a sub-workflow's input paths genuinely differ in contract shape (binary vs JSON, sync vs async, divergent auth), the fix is not one passthrough trigger with an internal Switch - it's an "N+1" split: one outer sub-workflow per distinct input contract doing its own input-specific prep, each calling one shared downstream sub-workflow with a normalized shape that knows nothing about which outer called it. A sub-workflow with a typed Define Below trigger doubles naturally as an AI-agent tool, since the agent fills the declared fields via $fromAI and the returned shape becomes the tool's observation - the zero-input case still works as a tool (the agent's only decision is whether to invoke), but the binary case does not wire cleanly as a tool since agents can't pass binary directly.

Use it when shared or multi-step logic should become a typed, reusable workflow, when an existing workflow is growing too hard to reason about, or when an agent needs a workflow exposed as a tool. Always preserve authentication and authorization boundaries when extracting logic - never place credentials in inputs or returned data - declare any state-changing behavior explicitly, and ask before running or activating a sub-workflow that sends, writes, deletes, or calls a billable external service. Do NOT default the Execute Workflow Trigger to passthrough outside the binary or zero-input cases - that silently blocks agent tool use and structured-caller binding. Do NOT extract a single HTTP call with no surrounding logic, and do not rename or remove a live input field without migrating every caller in the same change.

Inputs: the logic or side-effecting operation to encapsulate, its natural input types, and whether it needs binary support or takes zero arguments. Outputs: a named, discoverable sub-workflow with a typed Define Below trigger (or a documented passthrough exception), a description stating its input/output contract, a final Return Set node producing a natural output shape, and - for callers - the correct mode/waitForSubWorkflow combination for how it needs to run.

{
  "type": "n8n-nodes-base.executeWorkflowTrigger",
  "parameters": {
    "workflowInputs": {
      "values": [
        { "name": "list_of_ids",        "type": "array" },
        { "name": "include_transcript", "type": "boolean" },
        { "name": "session_id",          "type": "string" }
      ]
    }
  }
}

Built on n8n's Execute Workflow Trigger and Execute Workflow node pair, discoverable via n8n_list_workflows/n8n_get_workflow, configured via n8n_update_partial_workflow, and validated with validate_workflow/n8n_test_workflow. Stateful sub-workflows commonly back onto a Data Table (n8n_manage_datatable), and cross-references companion skills including n8n-agents (wiring a sub-workflow as an agent tool), n8n-binary-and-data (the binary-input passthrough case), n8n-error-handling (the expected-return vs throw boundary), and n8n-expression-syntax (reading trigger inputs).

n8n workflow builders who need to turn shared or multi-step logic into a properly contracted, discoverable, reusable sub-workflow instead of copy-pasting it across workflows.