Script

Runs a short script in a sandbox and hands its result to the rest of the flow. Reach for it to reshape data between two steps—flattening a response, filtering a list, computing a value—when no purpose-built action fits.

Fields

Field	Description
Brightspot Connection	Optional. Leave empty for the script's dari SDK to describe this workspace's content types. Pick a Brightspot connection for it to describe that CMS's content model instead.
Language	The language the script is written in. Choosing JavaScript reveals its Script field, holding the source.
Script	The source code. It is checked for syntax errors as you type, and the field carries a note summarizing the sandbox and the variables available.
Output Type	The shape of the value the script returns, so later steps can reference its fields by name.
Auto-generate Output Type	Infer the output type from what the script actually returned on the automation's last finished run, instead of declaring it by hand. Disappears once an output type exists. Checking it before the automation has ever run leaves the box checked, so the next save after a run picks it up.

The script is needed to run, not to save. Leave it empty and the step shows a needs-attention note rather than blocking the save, so you can lay out a flow before writing its code—see Building automations. At run time, an empty script fails the step.

Where the script comes from

The Script field chooses one of three sources.

Source	What it is
Inline	The script is written on the step, in a language you choose. What every Script step was before the catalog existed, and still the default.
Saved	The step references a script from the Scripts catalog by name. The reference is live: the step runs whatever the saved script holds when the step runs, so an edit in the catalog reaches every step that references it. The step shows the chosen script's code read-only, with a link to edit it in the catalog. On the canvas, the step is labeled with the script's name.
Runtime	The script's code arrives at run time from a value produced earlier in the run: bind Source to a field holding the code—a file fetched by an HTTP Request or a GitHub Get File Contents step, a variable. The route for code kept somewhere Esca has no connection to. The sandbox is unchanged; what changes is who can change the code, so trust the source as you trust the automation reading it.

A Saved source whose script has been deleted, or a Runtime source whose value is not text, fails the step at run time with a message saying so.

Writing the script with Esca

On an Inline script, Esca can write the Script field for you. Where a model is configured for the site, a hint appears over the field's label—click it, or place the cursor in the field and press Ctrl+Enter (Windows/Linux) / ⌘+Enter (Mac), to open its card beside the node panel.

What the keyboard shortcut does depends on what is already in the field:

• An empty field opens the card with starters for a first draft, such as Log what arrives? and Pull out fields.
• Plain-language text that is not already code becomes the script's opening comment, and the shortcut asks Esca to write the code underneath it.
• A // comment on its own line asks Esca to write the code that follows it.
• A selection, or a blank line inside existing code, opens the card asking what should go there; the lines in question stay highlighted while you answer.
• Pressing the shortcut again while Esca is writing stops it and puts the field back the way it was.

Esca streams the result into the field as one undoable edit—Undo reverts the whole write in a single step—while a moving outline traces the field and the card lists its progress.

Once the field holds code, the card's starters change to Explain, Tidy, Add comments, Warn on missing values, and Check field names. Check field names compares every payload and input read the script makes against what the automation actually provides—the step before it, the mappings on its Input tab, and, right after a content trigger, the fields of the content types it watches—and offers to fix anything it finds, such as a misspelled or moved field. Running it from a selection checks and fixes only those lines. When the step's content fields cannot be read—no content types chosen yet, or a connected CMS too old to describe them—Esca says why instead of guessing.

Esca cannot help with a Saved or Runtime script, since there is no field here for it to write into.

What the script can read

Three values are available:

• payload—the output of the step immediately before this one. It is not defined at all when that step produced nothing, so a script that might run in that position should test typeof payload !== 'undefined' rather than reaching for optional chaining, which does not survive an undefined name.
• input—the values you mapped into the step on its Input tab, reachable as input.fieldName. A mapping whose value resolved to nothing, such as a field the content leaves unset, is null.
• dari—the content SDK, which knows the content types defined in this workspace, or a connected Brightspot CMS's content model when Brightspot Connection is set, so a script can build a record for a Content Edit action to save. See Content scripting.

The value the script returns is the step's output. That value is the last expression evaluated: a top-level return is not supported.

console.log(), console.warn(), and console.error() are captured as timestamped entries in the step's own execution log.

What later steps see

With an output type declared, later steps see its fields. A value with no fields to expose—a single number or string, a list, or an object declared with no fields—is offered whole under payload. With no declared type, the shape is unknown to later steps until the script has run at least once.

Limits

Scripts run with no access to the file system, the network, or the host. Several ceilings bound what one script may consume, because the server runs many at once and none of them should be able to slow the others down. Script steps are meant for transforming data, and the defaults sit well above what that needs.

What is limited	Default
Time to run	3 seconds
CPU time used	1 second
Statements executed	1,000,000
Memory held at once	32 MB
Memory allocated in total, including memory the script discards as it goes	192 MB
Longest single string	4,194,304 characters
Largest single typed array, such as a Uint8Array	1,048,576 elements
Console output captured per run	64 KB
Length of the script itself	262,144 characters

For scale: a script that maps and filters a 50,000-item list and re-serializes it to JSON uses roughly 250,000 statements, under a tenth of a second, and under 4 MB of memory.

Crossing a ceiling fails the step with a message naming the one you crossed, so you can tell which value is in the way. Your administrator can change any of them—the two memory ceilings and the CPU ceiling additionally depend on how the server is set up—but the message always names the ceiling that stopped the script.

If you are hitting a limit, the usual fix is to move work out of the script rather than raise the ceiling: filter a list before the script rather than inside it, or split one large script into several steps.