Code

The Run code template executes JavaScript in a sandbox and returns a single result. Expression variables in the source are replaced with values before the script runs; the return value is coerced and exposed on the execution record for downstream steps. Random number and iteration helpers live in the same Code group — see those articles from the hub.

Run code

Code
JS

Execute JavaScript code in a sandbox environment and return a single result.

What this step does

The Run code step runs a short Node.js snippet in an isolated sandbox (separate from your browser and the editor). Use it for deterministic glue: parse or reshape JSON, compute a value, or prepare data for a webhook, document, or AI step, without model drift or browser APIs.

Return value and {{exe.result}}

The value produced by the top-level script body (your return or the final expression the runner treats as the result) is the primary execution result. After the run, that value is available on the execution record as {{exe.result}}for the Output tab and for later steps when you map fields from this step's execution.

The runner also exposes {{exe.execution_ms}}: total execution time in milliseconds for the code run. Use it in output mappings or debugging without re-parsing stdout.

Expression variables inside the source

Any expression variable you type in the JavaScript field is resolved to a literal value before the sandbox executes. The runtime never sees the raw {{…}} tokens: only the substituted text or JSON that the template engine produced.

The previous step's payload is still passed into the sandbox as the input binding. You can use input and tags together: tags become fixed literals in the emitted source; input stays a live object at run time.

Example tokens below use the same light purple monospace chip styling as tags in the editor palette.

ValueDescription
{{input.hello}}Example inbound field, resolved from the previous step or your Input schema before the script runs.
{{exe.result}}Coerced return value from this step after the sandbox finishes (primary execution result).
{{exe.execution_ms}}Total execution time in milliseconds for the code run.

String concatenation

If {{input.hello}} resolves to the string "World!", then source like return "Hello " + {{input.hello}} becomes return "Hello " + "World!" before execution, and the result is "Hello World!".

More patterns (what you type in the editor)

After tags are replaced, the file is ordinary JavaScript. You can place tags inside functions, branches, template literals, or anywhere a literal could appear. The following shows typical source before the runner substitutes each {{…}} token.

// Tags in a helper: values are fixed before the sandbox runs
function greet(name) {
  return "Hello, " + name;
}
return greet({{input.name}});

// Tag in a switch (often wrap with String(...) if cases are string labels)
switch (String({{input.status}})) {
  case "done":
    return { ok: true };
  default:
    return { ok: false };
}

// Tag as a binding, then a template literal (readable when ids are dynamic)
const orderId = {{input.order_id}};
return `Order ${orderId} is ready`;

// Tag as a numeric literal
const n = Number({{input.count}});
return n * 2;

Choose Result type so the coerced return matches what you emit (for example JSON for objects, Number for numeric returns).

Execution tab settings

These fields appear on the Execution tab when you select a Run code step in the workflow editor.

FieldDescription
Timeout (seconds)Maximum wall-clock time for the sandbox run. The control allows 1 to 60 seconds (values outside that range are clamped). If execution exceeds the limit, this step fails so you can branch or retry downstream.
Result typeHow the runner coerces the value your script returns: String, Number, JSON, or Null. It should match what the code actually returns. For example, returning an object while Result type is String can cause coercion or step errors. Prefer JSON for objects or arrays and Number for numeric results.
JavaScript sourceThe runnable source. Type {{ for tag completion. Prefer returning a value for the main payload; use console.log sparingly because stdout may be truncated in storage.

Output tab

Map each output row's value from expression variables (typically {{exe.*}}) into the JSON object the next step receives as input. Use Import from execution to add suggested rows for the common exe fields below; you can still add custom keys and bind any tag the runner resolves after this step runs.

ValueDescription
{{exe.result}}Coerced return value from the JavaScript snippet (stdout protocol).
{{exe.execution_ms}}Total execution time in milliseconds for the code run.
{{exe.exit_code}}Process exit code from the Node runner inside the sandbox.
{{exe.active_cpu_ms}}Sandbox-reported active CPU milliseconds when the platform exposes it after the VM stops.
{{exe.stderr}}Captured stderr from the snippet (truncated in the payload when very long).

When to use Run code

  • You need logic that is awkward to express with AI prompts or fixed templates alone.
  • You want predictable behaviour and cost (no model sampling).
  • You must transform upstream data with strict control before a webhook, document, or termination step.

Security and side effects

Treat the sandbox as ephemeral. Do not rely on hidden local disk between runs unless the product explicitly documents it. Do not embed long-lived secrets in source; use workflow constants or patterns your organisation approves. Be cautious calling untrusted URLs from inside the sandbox unless you understand egress rules for your environment.

Related