Skip to main content
The return output ends a reusable section and decides what it hands back. It declares the return contract, and it fills that contract from the section’s own node outputs. A section has at most one: two returns would make the result depend on which branch ran. A section with none is still callable as a terminal stage - it ends in its own output (a Business Central or QuickBooks write, callback, email) and its caller’s call completes with an empty payload. Add a return only when the caller should continue with the section’s data; see Reusable sections.

Configuration

Return contract

The contract is what callers read. Every field you declare here appears in the field picker of any node placed after a Call workflow action that targets this workflow.
Changing the contract can break callers that already read these fields. Removing or renaming a field leaves those references pointing at nothing.

Field mappings

Map each contract field from the section’s own node outputs, the same way a Transform action maps fields. Field coordinates are carried through, so a value extracted inside the section can still be highlighted on the document by the caller: the section ran on the same document, so the coordinates stay valid.

Only one per section

Branches converge into a single return. If your section branches, wire every branch that should hand something back into the same return node. Two returns would make “what did the call hand back” depend on which branch happened to run, so Ingestly rejects a second one when you save. Zero returns is fine: that is a terminal section, and its caller’s call completes with an empty payload. A section that declares a return but finishes without executing it has broken its promise, and the calling step fails. If some terminal path in your section cannot reach the return, Ingestly warns you at save time.

Testing a section without a caller

The return payload is always materialized, so it is the run’s visible result even with nobody calling. Give the section an upload trigger alongside its sub-workflow trigger, submit a document, and read the return node’s output: that is exactly what a caller would have received.

Inputs and outputs

Allowed inputs: any action node. Output: terminal node, no downstream connections inside the section. The payload is delivered to the calling step.

Credits

Free. Only the section’s other steps bill.

Sub-workflow trigger

The other half of a section’s interface

Call workflow action

Consume this payload from another workflow

Reusable sections

The whole pattern, end to end

Transform action

The same mapping tree, used to reshape data mid-workflow