Function

A Function node runs custom JavaScript against each message that passes through your flow.

Use a Function node when the built-in nodes are not enough for the transformation, branching, or state management you need. The incoming message is available as the JavaScript object msg, and by convention the main value being worked on lives in msg.payload.

Safe default

In Contextual flows, the safest pattern is to mutate msg and return msg.

msg.payload = String(msg.payload).trim()
return msg

This preserves runtime-owned fields such as msg._contextual, msg.req, and msg.res.

If you need to build a new object, spread the original message first:

return {
  ...msg,
  payload: String(msg.payload).trim(),
}

Do not return a brand-new object that omits runtime fields, and do not use return null in agent flows. Returning null stops that execution path without reaching Event End, Event Error, or another terminal node.

Sending messages

For most single-output cases, return msg.

Advanced patterns are still available when needed:

• return an array of messages to target multiple outputs

• return nested arrays to send multiple messages from one output

• call node.send(...) for asynchronous or more advanced patterns

The editor's On Start tab runs when the node starts, and On Stop runs when the node stops. If On Start returns a Promise, the node waits for it to resolve before handling messages.

Available runtime objects

Function nodes have access to these runtime objects:

• msg - the current message being processed

• node - the current node instance and its helper methods

• logger - async execution logging helpers: debug, info, warn, and error

• context - node-local state for this Function node

• flow - shared state for nodes on the same tab

• global - shared state across tabs in the same runtime

• env - environment-variable access via env.get("NAME")

Prefer msg for values that belong to one in-flight execution. Use context sparingly for node-local state. Treat flow and global as advanced shared-state tools and avoid them unless you have a specific reason to coordinate state across nodes.

Contextual flows may also include values such as msg.event, msg.req, msg.res, and msg._contextual. Treat msg._contextual as runtime-owned metadata.

Logging and errors

Prefer logger when you want logs to appear in Contextual's execution logs.

await logger.info("processing customer %s", msg.payload.id)
return msg

The node object still exposes runtime logging helpers such as node.log(...), node.warn(...), and node.error(...), but they are not the preferred default for Contextual execution logging.

To enter a Catch path, throw an error. If you need to attach the current message, use node.error(..., msg):

throw new Error("Something went wrong")

node.error("Something went wrong", msg)

Libraries

Function nodes also support configured library imports in the editor. The exact set of available modules depends on runtime configuration, so validate imports in a development tenant before relying on them in production flows.

Common uses

• normalize incoming payloads before writing to an Object Type

• prepare values for HTTP Request, AI, or Object nodes

• set flags or status fields used by a downstream Switch node

• keep small amounts of node-local state in context when simpler message-based flow design is not enough