Function Def Start

Overview

Function Def Start begins a reusable function subgraph. Connect body nodes from this start to a Function Def End. Runner nodes on a trigger path then call this definition by selecting this node.

This node has no input handle. It is not part of a trigger flow; it defines a function that runners invoke.

Input

Function Name

string required

Display name of the function being defined.

Function Arguments Schema

string required

JSON schema for the function arguments. This schema is published as this node's outValue so body nodes can reference typed argument fields.

Runners do not have argument inputs. Values in outValue are filled when this Start node runs: each schema field copies a referenced flow value if that pointer exists, otherwise the field default, otherwise an empty value of that type.

Use the schema builder in the node form. You can reference types from downstream body inputs (this types outValue for the body). You can also point fields at values that already exist when Start runs, such as earlier nodes on a series path or shared variables.

Default: empty string

Output

outValue

object

Function arguments. Structure and field types follow the configured Function Arguments Schema.

How function nodes work together

Function definition and function runners are separate subgraphs.

Define the function

1. Place Function Def Start and Function Def End.
2. Connect body nodes from Start to End. Start has no input handle; End has no output handle.
3. Set Function Arguments Schema on Start (available to the body as outValue).
4. Set Function Return Schema on End (this becomes the runner's outValue).

Pairing rules at deploy:

• Each Function Def End must have exactly one Function Def Start upstream.
• Each Function Def Start may have at most one Function Def End downstream.

You cannot connect a function subgraph to a trigger subgraph. They stay on separate paths.

Call the function

Place Run Function Series or Run Function Parallel on a trigger path. In Function Definition Node, pick this Function Def Start (it can be anywhere on the canvas).

• Series runs the function on the same flow path and waits until it finishes.
• Parallel runs the function on a separate path. Nodes between that runner's Start and End handles run once on the current path. Wait for Function to Finish controls whether the current path waits.

The runner outValue follows the paired End node's Function Return Schema.

Arguments and return values

Callers do not pass a payload on Run Function Series or Run Function Parallel. Data moves in three ways:

1. Start outValue (arguments). Built from this node's Function Arguments Schema when the function starts. Body nodes read it like any other node output.
2. Body NabrioRefs and variables. Body nodes can reference other node outputs and shared variables. On a series call the body runs on the same path, so it can also read nodes that already ran on that trigger path. On a parallel call the body runs on a separate path; use shared variables for live shared state. Other node outputs the body references are read from published values when that parallel run starts.
3. End outValue (return). Built from the End node's Function Return Schema, usually by pointing fields at body outputs. When End runs, that object is copied onto the runner outValue. Downstream of the runner reads the runner, not End.

Series execution

Run Function Series always waits. The current path jumps into this Start node, runs the body, then End copies the return onto the runner and continues the runner's default output. End does not finish the trigger path.

Parallel execution

Run Function Parallel starts the function on a separate path that begins at this Start node. The trigger path is not completed by that function path finishing.

The runner's Start / End handles are not the function body. They are an optional once-through sidecar on the current path (work that should run once while the function runs aside).

Wait for Function to Finish:

• On, no sidecar: the current path pauses at the runner until End, then continues the default output. outValue is this call's return.
• On, sidecar wired: the current path goes out Start, through the sidecar, and back to End. If the function is still running, it waits there, then continues the default output. outValue is this call's return.
• Off: the current path continues immediately (Start sidecar if wired, otherwise the default output). outValue is the last completed return of this function, from when the runner fired — not the run that just started. Until this function has finished at least once, outValue may be empty.

If the same function runs more than once at the same time (two triggers, or wait-off overlapping calls), each overlapping run uses its own body-node instances so local body state does not mix. Shared variables stay shared.

Nested functions and recursion

A function body may contain Run Function Series or Run Function Parallel nodes that call another function, or this function again.

• Nested and recursive calls are allowed.
• Maximum call depth is 8 (counting series and parallel calls on that path). Deeper calls fail at run time.
• For a recursive series call, each invocation keeps its own body outputs. When the inner call returns, the outer call's body outputs are restored so the inner run does not overwrite them.

Typical setup

1. Define the function (Start → body → End) with no connection to any trigger.
2. Point End return fields at the body outputs you want the caller to receive.
3. On a trigger path, place Series or Parallel and select this Start.
4. Downstream of the runner, read the runner outValue.
5. Pass live data into the body with shared variables, or (series only) by referencing nodes that already ran on the same path.