> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ingestly.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Reusable sections
> Build a block of steps once and call it from every workflow that needs it.
When several workflows need the same block of steps, you can build that block once as its own workflow and call it from each one. Ingestly calls that a **reusable section**.
A section is an ordinary workflow with a [Sub-workflow trigger](/nodes/sub-workflow-trigger) that declares what it needs, and - when the caller should get data back - a [Return output](/nodes/return) that declares what it hands back. Any other workflow then runs it with a [Call workflow action](/nodes/call-workflow). A section that is the last stage of the job can skip the return and end in its own output instead.
## When to use a section
Use a section when the same steps appear in more than one workflow and you want one place to change them: a vendor lookup, a totals reconciliation, a compliance check.
Use a [Forward output](/nodes/forward-output) instead when you want to hand the **document** to a different workflow that owns the next stage of its life. Forwarding creates a new document with its own run; calling keeps one document and one run.
## Build the section
1. Create a workflow for the section
2. Add a **Sub-workflow trigger** and declare its input contract: the fields callers must supply. Leave it with no fields if the section only needs the document
3. Build the steps
4. If the caller should continue with the section's data, add a **Return** node, declare its return contract, and map the section's outputs into it
5. Converge every branch that should hand something back into that single return; a section ending in its own output (for example a connector) needs no return, its caller's call completes with an empty payload, and the call node may end the caller's branch outright
The workflow is callable as soon as it has a sub-workflow trigger. It then carries a **Section** label on the Workflows page, and the sidebar's **Sections** view lists every section in the workspace.
Add an upload trigger alongside the sub-workflow trigger while you build. Submitting a document runs the section on its own, and the return node's output is exactly what a caller would receive, so you can test the section before anything calls it.
## Convert existing steps into a section
If the steps already exist inline in a workflow, you do not have to rebuild them. Select them on the canvas and convert them into a section directly.
1. Select whole branches. The selection needs a single entry point and a single exit point, and the exit must leave from one output port.
2. Open **Convert to section**. Ingestly reads every reference crossing the edge of your selection and shows you the input and return contracts it derives, before you commit to anything:
* A value a selected step reads from a step outside the selection becomes an **input**.
* A value a step outside the selection reads from a selected step becomes a **return**.
3. Name the section and confirm.
Some selections cannot convert, and Ingestly names exactly what to fix. Common reasons: the selection contains a trigger, is not one connected group, has more than one entry or exit, leaves from an error port, splits a loop body from its loop container, or branches (an If or a Switch) on a step outside the selection. A Transform or Validation script that reads across the boundary is rewritten automatically where that is safe, and refused by name when it is not. Validate rules are rewritten too: a rule that checks a value from outside the selection becomes an input, and a rule outside that checks a value the section produces reads it back from the call.
Confirming creates the section as a new workflow, saves the extracted steps onto it, and **activates it immediately** - the section inherits this workflow's group and retention automatically, and neither is ever asked for. The selected steps are replaced here by a Call Workflow node wired to it.
The workflow you converted from is left **unsaved**. The section is already live, but this workflow still needs a save before the new Call step sticks.
Sections created this way count against your plan's workflow limit like any other workflow. If you are at the limit, the refusal comes from the server when you confirm.
## Call it
1. In the calling workflow, add a **Call workflow** action
2. Pick the section. Only callable workflows in the same environment appear, and never the workflow you are editing
3. Fill the mapping rows the section's input contract created
4. Continue building after the call. Nodes placed after it can read the section's return fields, for example `{{Call section.payload.data.total}}`
Two call nodes may target the same section, in the same workflow or in different ones. That is the point.
## How a call runs
The section runs as a **sub-run** of the calling run, on the same document. No copy of the document is made.
* The call **always waits** for the section and then continues with its result
* Top-level run lists show one entry for the whole thing, not one per section
* The calling run's detail nests the section under the call step, named after the workflow it ran, so you can open it and read its steps
* If the section fails, the calling step fails with the section's error and a link to its run
* If the section finishes without reaching its return, the calling step fails: nothing was produced
## Reviews inside a section
A section can contain a [Review action](/nodes/review). The call waits for the reviewer, with no timeout: the wait is durable and survives restarts.
The caller's run detail marks the section **in review**, so a section parked on a person is visible from the calling run without opening it.
## Limits
A workflow cannot call itself, and Ingestly rejects a call chain that comes back around (A calls B, B calls A) when you save. A runtime depth cap of 10 backs that up, so a chain assembled by editing several workflows separately still stops.
## Credits
The three section nodes are free: the call, the sub-workflow trigger and the return. The section's other steps bill normally, on the section's own run. Calling a section costs the same as the steps would have cost inline.
## Changing a contract
Both contracts are interfaces, so changing one affects the workflows on the other side.
* Change the **input** contract and callers whose mappings no longer satisfy it are flagged and disabled when you save, until their mappings are fixed
* Change the **return** contract and callers reading a removed field are left pointing at nothing
Saving a contract change pauses every caller whose mapping no longer fits, and the editor warns you before that save completes: it names the callers about to pause so the breakage surfaces then, not on their next run.
## Related
Run a section and use its result
Declare what a section needs
Declare what a section hands back
Hand the document off instead