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

# Return

> Declare and fill what a reusable section hands back to its caller.

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](/guides/reusable-sections).

## Configuration

| Field               | Type           | Required | Description                                                       |
| ------------------- | -------------- | -------- | ----------------------------------------------------------------- |
| **Return contract** | schema builder | Yes      | The shape this section hands back                                 |
| **Field mappings**  | mapping tree   | Depends  | One entry per contract field, filled from the section's own nodes |

### 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](/nodes/call-workflow) that targets this workflow.

<Warning>
  Changing the contract can break callers that already read these fields. Removing or renaming a field leaves those references pointing at nothing.
</Warning>

### Field mappings

Map each contract field from the section's own node outputs, the same way a [Transform action](/nodes/transform) 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.

| Path               | Type   | Description                                              |
| ------------------ | ------ | -------------------------------------------------------- |
| `payload.dataJson` | object | The mapped return payload, shaped by the return contract |

## Credits

Free. Only the section's other steps bill.

## Related

<CardGroup cols={2}>
  <Card title="Sub-workflow trigger" icon="arrow-turn-down-right" href="/nodes/sub-workflow-trigger">
    The other half of a section's interface
  </Card>

  <Card title="Call workflow action" icon="phone-arrow-up-right" href="/nodes/call-workflow">
    Consume this payload from another workflow
  </Card>

  <Card title="Reusable sections" icon="recycle" href="/guides/reusable-sections">
    The whole pattern, end to end
  </Card>

  <Card title="Transform action" icon="repeat" href="/nodes/transform">
    The same mapping tree, used to reshape data mid-workflow
  </Card>
</CardGroup>
