Reusable sections

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 that declares what it needs, and - when the caller should get data back - a Return output that declares what it hands back. Any other workflow then runs it with a Call workflow action. 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 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.

​

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.

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. 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