Return

Ends the whole flow from anywhere, including inside a loop.

Purpose

Finalizes the run with a declared status and message, exactly like Stop — but designed to be reachable from deep inside a structure where a Stop would read badly, most often inside a loop region.

When to use it

• Ending the flow from inside a loop, where Break would only leave the loop.
• An early exit from a nested structure.
• A guard clause deep in the graph that should end everything.

When not to use it

• To leave a loop but keep going — use Break.
• To skip one loop pass — use Continue.
• At the natural end of a flow — Stop reads more clearly as a terminus.

Requirements

None beyond a final status.

How it runs

Return finalizes the run immediately with its declared status and message. Like Stop, it is terminal: no edge is resolved, and it has no output ports.

The distinction from Break matters:

Settings

Setting	Type	Range	Notes
Final status	choice	success, failure, cancelled	The run's outcome
Message	string	≤ 500 chars	Optional. Appears in the run log

Identical to Stop — the difference is intent and placement, not configuration.

Ports

Return is a terminal node. It has no output ports.

Basic example

Abort from inside a loop when a hard limit is hit:

• Final status: failure
• Message: "Hit the safety limit"

Realistic example — abandon on a fatal condition

Two very different exits from the same loop:

• Break — normal completion. The flow continues to "Report totals".
• Return — something is wrong. Nothing after the loop should run.

Using Break for the second case would produce a misleading "success" report on a broken run.

Advanced example — guard clauses in a Sub Flow

In a called flow, Return is how a guard states the child's result without threading a path all the way to the bottom of the graph:

Each guard returns immediately with a specific message. The parent's Sub Flow node branches on Success or Failure, and the messages explain which guard fired.

Note R3 returns success — "already at capacity" is a correct outcome, not a failure.

Best practices

• Use Return for "stop everything", Break for "stop this loop". Choosing wrongly produces wrong reports.
• Always write a message, exactly as with Stop.
• Prefer Return for guard clauses, Stop for the natural end of the flow. The visual distinction helps readers.
• In a Sub Flow, be deliberate about the status — it is the child's return value to its caller.
• Do not scatter Returns everywhere. A graph with fifteen exit points is hard to reason about; group guards near the top.

Performance notes

• Return costs nothing and consumes one execution against maxNodeExecutions.
• Returning early is the cheapest outcome available — a guard that returns immediately skips the entire rest of the flow.

Memory notes

• Finalizing releases the run's execution context, including run-scoped Runtime Memory.
• Scopes above run survive, by design.

Common mistakes

Mistake	What happens	Fix
Return where Break was meant	Ends the whole run	Use Break
Break where Return was meant	Flow continues and reports success on a broken run	Use Return
No message	Unreadable logs	Write the reason
failure for a legitimate no-op	Parents take recovery paths needlessly	Use success
Many scattered Returns	Hard-to-follow graph	Group guards near the top

Troubleshooting

The flow ends earlier than expected. A Return was reached. The run log's final message identifies which one.

A loop stops but the run continues. That was a Break, not a Return.

The parent flow took the recovery branch unexpectedly. A Return in the child declared failure. Check whether that outcome is genuinely a failure.

FAQ

What is the difference between Return and Stop? Behaviourally nothing — both finalize with a declared status. Return is intended for early exits from inside structures; Stop for the flow's natural terminus.

Does Return exit only the Sub Flow, or the whole run? It finalizes the flow it is in. In a child, that ends the child and returns control to the parent's Sub Flow node.

Can I wire anything out of Return? No — it is terminal.

Does it count toward maxNodeExecutions? Yes.

Related nodes

• Stop — the natural terminus
• Break — leave a loop only
• Continue — skip one pass
• Sub Flow — consumes the returned status

Related pages

• Execution Model