Watch the tutorial

The Function Node executes custom JavaScript code within a workflow. It is the primary mechanism for performing data transformations, calculations, format conversions, and custom business logic that cannot be handled by the visual workflow builder alone. The code runs in a secure sandboxed environment, and the results are stored in the Data Center for use by downstream nodes.

When to Use

Use a Function Node when your workflow requires:

• Data transformation — restructuring, filtering, or enriching data from previous steps.
• Format conversion — converting between XML, JSON, date formats, or encoding schemes.
• Calculations — computing sums, differences, durations, or derived values.
• String manipulation — encoding, decoding, generating random strings, or parsing complex text.
• Custom business logic that cannot be expressed through standard workflow nodes.
• Preparing payloads before calling an external API via an Action Node.

Configuration

Code Type

The Function Node supports three ways to author the JavaScript code:

Writing the Code

The code must define a function named execute that accepts the configured arguments and returns a result. Common libraries are available inside the sandbox, including lodash (as _), luxon, xml2js, and the standard crypto and Buffer APIs.

Example — simple date formatting:

function execute(dateString, format) {
  return luxon.DateTime.fromISO(dateString).toFormat(format);
}

The return value of execute becomes the node's output, accessible in downstream steps via the Data Center.

Arguments

Arguments are an ordered list of values passed into the execute function. Each argument can contain Data Center template expressions (e.g., {{nodes.input_1.executionData.startDate}}), which are resolved to their actual values at runtime before the code runs.

Test Code and Test Arguments

The node provides a separate test configuration that lets you test the function from the workflow builder UI without triggering a full workflow execution. Map test arguments to representative sample data and verify the output before deploying.

Output Mapping

Output mapping lets you write the function's return values back into form fields or global constants, making them available to subsequent human-facing steps (Input or Approval Nodes) or other parts of the workflow.

Each mapping entry has two fields:

Success and Error Messages

Fail Workflow Item

When enabled, if the function fails, the entire workflow item can be marked as failed (in combination with the Trigger Node's failure setting). Failed items are also surfaced in scheduled failure reports. Leave this disabled for non-critical transformations so the workflow can continue even if the function encounters an error.

Masked Fields

You can specify fields that should be masked in execution logs and audit trails. This is useful for sensitive data like passwords, API keys, or personal identifiers that pass through the function.

Progress Path

You can hide the Function Node from the progress tracker if it represents an internal computation step that shouldn't be visible to end users.

Pre-defined Functions

The following utility functions are available out of the box. Selecting one auto-populates the code editor with a tested implementation — you only need to map the arguments.

How It Works at Runtime

1. Arguments are resolved — all Data Center template expressions in the code and arguments are replaced with their actual runtime values.
2. Code executes — the resolved code runs in a secure sandbox. The execute function processes the arguments and returns a result.
3. Results are stored — the function's return value is saved in the Data Center and becomes available to all downstream nodes.
4. Output mapping runs — if mapping entries are configured, the function's output values are written to the specified form fields or global constants.
5. Success or failure — if the function completes successfully, the workflow continues to the next node. If it fails and Fail Workflow Item is enabled, the workflow item may be marked as failed. Otherwise, the error is logged and the workflow proceeds.

Best Practices

• Start with pre-defined functions for common operations like date formatting, encoding, or XML conversion. They are tested and optimized — no need to reinvent them.
• Use the test feature to validate your code before deploying. Map test arguments to representative sample data and verify the output.
• Keep functions focused and small. If you need complex multi-step logic, consider splitting it across multiple Function Nodes for easier debugging.
• Use output mapping to write results to form fields when the data needs to be visible in a subsequent Input or Approval step. Use global constants when the value should be available workflow-wide.
• Configure error mapping for functions with multiple failure modes so users see meaningful error messages rather than generic failures.
• Enable Fail Workflow Item only when the function is critical to the workflow's success. For non-critical transformations, leave it disabled.
• Mask sensitive fields — if your function processes passwords, tokens, or personal data, add those fields to the masked fields list.
• Use AI code generation for rapid prototyping — describe what you need in plain English, review the generated code, and refine as needed.