Skip to main content

​
Functions

A Function step calls one built-in function. You pick the function from a list, write a JSON Payload for it, and the value it returns becomes the step’s result. There are 31 built-in functions. They fall into four groups:

Key-Value Storage

Five functions for buckets of small values addressed by key

Object Storage

Five functions for buckets of larger objects — files, documents, exports

Streams

Nine functions for append-only message streams and their aggregation

Utilities

Nine functions for encoding, templating, format conversion and file transfer
The remaining three — Delay, HTTP and Rules — are in the same catalogue but have their own step types. Use the Delay, HTTP Request and Rules steps rather than a Function step, because those steps give you a proper editor for the same operation.

​
Every function

Names are exactly as they appear in the picker, including capitalisation.

​
Configuring a Function step

The node editor has two tabs, and two more in advanced mode: The form on the Function tab is built from the function’s declared input schema, so the fields you see are the parameters that function accepts. JSON Editor opens the same payload as raw JSON, validated against that schema. The payload is sent to the function exactly as written, after JSONPath resolution. Any string beginning with $. is resolved against the run’s data first — see Variable Mapping.
There is no request envelope. The payload is the function’s input. A payload of {"bucket": "orders", "key": "ord_88"} reaches get-kv-bucket-item as exactly that object.

​
Reading the result

The result is stored flat under the step’s ID. If the step ID is GET_ORDER:
There is no .output or .result wrapper. Most functions return the same envelope:
Write functions return {"status_code": …, "body": {"message": …}} or {"status_code": …, "body": {"error": …}} instead, and the pure utilities (base64-encode, Handlebars Template, JSON-XML, SFTP) return a bare string.

​
How a function fails

A function that returns an error object still counts as a successful step. Several functions handle their own errors by returning {"error": "…"} rather than throwing. The invocation succeeded, so the run carries on and the next step reads {"error": …} where it expected data.Test for it explicitly with a Condition step on $.STEP_ID.error, or on $.STEP_ID.status_code where the function returns one.
Three things do end the run:
  • The function throws and the runtime cannot catch it.
  • The invocation itself fails — the function could not be reached, or did not run.
  • The call exceeds its timeout — 20 seconds unless you set one in Advanced Settings.
An inner status_code of 409 or 404 in the body is not one of these. The invocation succeeded; the step succeeded; only the operation did not. There is no per-step error branch. The first step that errors cancels the whole run — see Building Reliable Flows.

Functions Step

Adding and wiring a Function step

Variable Mapping

Writing the $. expressions in a payload

Building Reliable Flows

Retries, timeouts and what a part-completed run leaves behind

Eval Step

JavaScript, for anything no function covers