Short answer: Put repeated work in a sub-workflow. Pass a small, documented input object. Return a predictable output. Keep ownership, errors, and execution mode clear at the boundary.

What belongs in a sub-workflow?

A good sub-workflow owns one operation. Examples include normalizing a customer record, creating a support ticket, or turning an API response into a stable internal shape. The parent workflow should not need to know every node inside it.

Do not extract a two-node action that has no reuse or separate test value. An extra boundary adds configuration and makes tracing longer.

How should inputs and outputs be defined?

Use a named input shape. Document required fields, optional fields, and the expected type of each value. The sub-workflow should return a stable object even when the source system changes.

Keep secrets in n8n credentials. Pass identifiers and business values through the input, not copied credential text. If the sub-workflow needs a credential, document which connection it uses.

What should the parent workflow handle?

The parent should decide when to call the sub-workflow and what to do with its result. It can route success and failure through an IF or Switch node. The child should report a useful error rather than silently returning an empty item.

Choose whether the parent waits for completion. A synchronous call is easier when the next node needs the returned data. An asynchronous design can fit long-running work, but it needs a status record and a way to reconcile completion.

How do you test the boundary?

Test the child with a minimal valid input, a missing required field, and a representative real value. Then call it from the parent and inspect the output item. Name both workflows so an execution list shows their relationship.

For broader branch design, see the workflow structure guide. For scaling many executions, see the queue and execution architecture guide.