Reference

Field-by-field reference for every node and connection type, grouped by kind and listed alphabetically. Use it to look up exactly what a node or connection exposes—its configuration fields, the options each one offers, and what a node outputs for later steps to read.

For task-oriented guidance, see the rest of the user guide—Building automations, Triggers, Actions, and the others.

Every node also carries a Display tab with optional Title and Description fields, not repeated in the field tables below—see Building automations.

Triggers

How automations start. See Triggers for choosing one.

Automation Completed trigger

Starts the automation when another automation finishes. Shown in the picker as Automation Completed, under General Triggers.

Fields

Field	Required	Description
Target Automation	Yes	The automation to watch for completion.
Outcomes	Yes	Which terminal outcomes to react to—Succeeded, Failed, or both. At least one is required.

The target cannot be the automation that owns the trigger.

Output

A completion snapshot of the target run: its execution identity, the payload that originally triggered it, timing, and—when it failed—an error summary.

Content trigger

Starts the automation when a content event occurs in a connected Brightspot CMS. Shown in the picker as Content, under Integration Triggers. Requires a Brightspot connection.

Fields

Field	Required	Description
Connection	Yes	The Brightspot connection whose CMS to watch.
Sites	No	Limit to specific sites. Leave unset to match any site.
Event	Yes	The content event to fire on (see below).
Filters	No	Narrow which content matches. With none, all content matches.

Events

Published, Drafted, Revised, Merged, Scheduled, Unscheduled, Transitioned (a workflow transition), Archived, Restored, Deleted, Commented, and On Demand.

Filters

Filter	Matches on
Types	One or more content types.
Field	A field's value on the content.
Content	Specific assets.
Match All	A group of filters that must all match.

Output

The event's payload—the affected content and event metadata. The exact shape depends on the selected event.

GitHub trigger

Starts the automation on a GitHub webhook event for a chosen repository. Shown in the picker as GitHub, under Integration Triggers. Requires a GitHub connection.

Fields

Field	Required	Description
Connection	Yes	The GitHub connection to use.
Repository	Yes	The repository to watch, as organization/repository.
Event	Yes	The event to fire on (see below).

Events

Push, Pull Request, Issues, Issue Comment, Pull Request Review, Pull Request Review Comment, Release, Create, Delete, and Workflow Run. Pull Request and Issues can be limited to specific actions; Create and Delete can be limited to branches or tags.

Output

The GitHub event's payload. The exact shape depends on the selected event.

Jira trigger

Starts the automation on a Jira event for a chosen project. Shown in the picker as Jira, under Integration Triggers. Requires a Jira connection.

Fields

Field	Required	Description
Connection	Yes	The Jira connection to use.
Project	Yes	The Jira project to watch.
JQL Filter	No	An optional JQL refinement, combined with the project filter—for example, priority in (High, Highest).
Event	Yes	The event to fire on (see below).

Events

Issue Created, Issue Updated, Issue Deleted, Comment Added, and Comment Updated. Issue Updated can be limited to changes in specific fields.

Output

The event's payload—the issue or comment involved.

note

Depending on the connection's authentication, the Jira webhook is registered automatically (OAuth) or set up by an administrator (API token). The node shows the current setup status.

On Demand trigger

Starts the automation when you run it yourself—with Run Automation in the editor—or when another automation calls it. Shown in the picker as On Demand, under General Triggers.

Fields

Field	Required	Description
Payload	No	The structured input the run starts with—a Content Type (an existing content type's fields) or a Custom Shape (fields you define on the trigger). Leave unset (None) to start with no input.

Output

If a payload is set, the trigger outputs its fields for later steps to read. With no payload, it produces no output.

Schedule trigger

Starts the automation on a recurring schedule, or immediately when you run it yourself with Run Automation. Shown in the picker as Schedule, under General Triggers.

Fields

Field	Required	Description
Payload	No	Structured input for each scheduled run—a Content Type or a Custom Shape. Leave unset for none.
Schedule	Yes	The recurrence, set as a cron expression.

Output

If a payload is set, the trigger outputs its fields; otherwise it produces no output.

note

The system checks for due schedules about once a minute, so a schedule that fires more often than once a minute may skip runs.

Webhook trigger

Starts the automation when an external system sends an HTTP POST to a generated URL. Shown in the picker as Webhook, under General Triggers.

Fields

Field	Required	Description
Name	Yes	A label used as the node's name in the editor.
URL	—	The endpoint to POST to. Generated automatically and read-only.
Signing Secret	—	A secret the external system signs its requests with. Generated on first save and kept stable afterward, so the sender's copy stays valid; unsigned requests are rejected.

Node actions

When the URL and signing secret are set, the node offers:

• Fire Test—send a test delivery to confirm the wiring.
• Deliveries—review past delivery attempts.

Output

The trigger does not define a fixed output schema; downstream steps read the posted request data through the variable picker.

Actions

The steps that do work. See Actions, Integrations, and AI and agents.

AI Agent action

Runs an AI agent on the automation server, drawing tools from one or more MCP servers. Shown in the picker as AI Agent, under AI Actions. Needs no connection. Supports human-in-the-loop.

Fields

Field	Required	Description
Template	No	A reusable agent from the Agents catalog that steers how this step approaches its task. The prompt below is sent as the task on top of it.
Prompt	Yes	The natural-language task for the agent. Accepts variables, so it can work on the trigger's data and earlier results.
MCP Servers	No	The tool sources the agent may use—a Brightspot environment or any MCP server. Add more than one to let the agent work across systems in a single run.
Payload Type	No	An output shape the agent populates as structured data, in addition to its message.
Human in the Loop	No	Opt-in. Set it to let the agent pause and ask a person before finishing, and choose the Providers the question is pushed to (for example, Slack)—every request is also answerable from the AI Approvals inbox. Left unset, the agent must finish on its own.

The node's Display-tab Description, when left blank, falls back to the start of the prompt.

Human-in-the-loop

When Human in the Loop is set, the agent can pause to ask a person for input—a choice or free text. The step waits until the request is answered, then the agent resumes with the answer.

Output

Field	Description
message	The agent's text response.
payload	The structured result, when a payload type is set.

Automation action

Runs another automation through its on-demand trigger. Shown in the picker as Automation, under General Actions. Needs no connection.

Fields

The action carries one operation, Trigger, with these fields:

Field	Required	Description
Target Automation	Yes	The automation to run.
Target Trigger	Yes	Which on-demand trigger of the target to start.
Input Payload	No	The structured input to start the run with. Shown when the target trigger defines a Content Type payload.
Input Payload (JSON)	No	The input as a JSON object instead. Shown when the target trigger defines a Custom Shape payload; accepts variables, and must evaluate to a JSON object matching that shape.
Wait For Completion	No	When on, this step waits for the target to finish and outputs its completion snapshot—a failed outcome can follow the error path. When off (default), it starts the target and continues immediately.

Output

• Fire-and-forget (wait off): a receipt identifying the run that was started.
• Wait for completion (wait on): a completion snapshot with the outcome, timing, and any error summary.

AWS AgentCore action

Invokes a hosted AWS Bedrock AgentCore agent. Shown in the picker as AWS AgentCore, under AI Actions. Supports human-in-the-loop.

Fields

Field	Required	Description
Agent	Yes	The hosted agent to invoke, chosen from your AWS environment's catalog of AgentCore agents.
Input	Yes	What to send the agent—a Prompt (text, accepts variables) or JSON (a structured payload, accepts variables).
Long-term Memory Scope	No	How much the agent recalls between runs: this run only; this node; this automation (the default); this agent across the site; or the whole site.
Human in the Loop	No	Opt-in. Set it to let the agent pause and ask a person before finishing, and choose the Providers the question is pushed to (for example, Slack)—every request is also answerable from the AI Approvals inbox. Left unset, the agent must finish on its own.

Human-in-the-loop

When Human in the Loop is set, the agent can pause to ask a person for input; the step waits for the answer and the agent resumes. While the agent works, its progress streams into the run.

Output

The agent's result, together with run telemetry. The result's shape is defined by the agent.

Content action

Operates on content in a connected Brightspot CMS. Shown in the picker as Content, under Integration Actions. Requires a Brightspot connection.

Fields

Field	Required	Description
Connection	Yes	The Brightspot connection to act on.
Target Content ID	No	A variable resolving to the ID of the content to operate on. Required for every operation except Save, where leaving it unset tells Save to create new content instead of updating existing content. If you bind a variable here and it resolves to nothing, the step fails rather than treating the empty value as a request to create.
Operation	Yes	What to do (see below).

Operations

Operation	Description	Extra fields
Fetch (deprecated)	Read the target content by id. Superseded by the Content Fetch action, which can also look content up by a unique field. Existing steps keep working; new ones should use the action.	—
Publish	Publish the target content.	—
Save	Save changes to the target content, create new content when no Target Content ID is set, or do either depending on whether the content exists (see Update, create, or both).	Create If Missing—creates the content when nothing is there instead of failing. Content Type—the type to create as; hidden for a Save that can only update. Differences—a JSON object of field changes keyed by record id, covering the content and every embedded object inside it (see below). Site—optional; the site to save in. It defaults to the connection's site when it pins exactly one, and otherwise the content keeps the site it already has.
Archive	Archive the target content.	—
Delete	Delete the target content.	—
Restore	Restore the target content.	—
Transition	Move the content through a workflow.	Workflow and Transition to apply.
Post Comment	Post a comment on the target content's conversation.	The comment to post.
Complete Work Stream Item	Mark the target content complete in a work stream, so the next run of a work-stream query skips it.	Work Stream—the work stream to mark the content complete in, typically the Content Query node's work stream output.

What an operation returns

The content it acted on, as id — a Save reports what it created just as one that updated reports what it changed. The two comment operations are the exception, returning contentId and postId; their field names predate the rest and existing automations reference them.

Update, create, or both

Three configurations, and the fields you fill in say which one you mean:

Target Content ID	Content Type	Create If Missing	What the step does
set	—	off	Updates the content at that id. Fails if nothing is there.
empty	set	off	Creates new content.
set	set	on	Updates the content at that id, or creates it there if nothing is there yet.
empty	set	on	Updates or creates the content the Differences name, whichever is needed.

The last two are upserts, and they are opt-in—a Save you already have keeps updating only. Use one when the same automation has to cope with content that may or may not exist yet: syncing from an external system, re-running an import, or reusing a tag if it is already there.

The fourth row is the one to reach for after a Content Script. A Save with no target takes the id from the root of its Differences, and a script puts the right id there either way—the one it fetched, or the one it minted for content it just built. Nothing in the automation has to know which case it is in, so no branch is needed.

An upsert refuses to run if the content is of a different type, since applying one type's fields to another would set whatever happened to match and drop the rest.

Unlike a plain update, an upsert that changes nothing succeeds. It asks for content to exist in a given state rather than for a change to be made, and finding it already that way is the request being satisfied—the ordinary result of running one twice.

If Target Content ID is bound to a variable that resolves to nothing, the step fails rather than treating the empty value as a request to create. An id that was supposed to be there and isn't is always a mistake, never an instruction.

A Save with no target needs its Differences to name exactly one record that nothing else links to—that is the content being saved. An empty Differences is refused rather than treated as new content: hand an upsert the whole record rather than a diff, so the id survives even when nothing changed.

Differences

Differences is one JSON object covering everything the save changes, keyed by record id: the content's own id keys its own field changes, and each embedded object inside it is keyed by its own id.

1
{
2
  "0000018f-1111-…": { "headline": "Storm closes harbor" },
3
  "0000018f-2222-…": { "text": "The harbor at dawn" }
4
}

Build it with a Content Script node—dari.diff(...) produces exactly this shape, and doing it by hand means knowing the id of every embedded object in advance. See Content scripting.

When creating, the new content takes the id the map already uses for it, so a Content Script that builds the content also names it. A map that names no single root gets a generated id instead.

You do not have to include _id or _type for the content itself—the step fills both in from the id and type it is using, and overwrites them if the map disagrees. Embedded objects are different: each one needs its own _id and _type, which is what a Content Script writes.

Saves configured before this field existed used a Fields box and an Embedded Objects list. Those still work and are upgraded to Differences the next time the automation is saved.

A Save that updates fails—rather than reporting success—when a change targets no content actually present (a misspelled or stale id) or changes no stored value. A Save that creates always produces new content, with its id available to later steps in its output.

Output

The result returned by the connected CMS for the operation performed.

Content Script action

Runs a script that knows the connected CMS's content model, so it can build and edit content with named types and fields. Shown in the picker as Content Script, under Integration Actions. Requires a Brightspot connection.

Identical to the Script action apart from the connection—same sandbox, same context, same limits—but its script gets a dari object for working with content. See Content scripting for the API.

Fields

Field	Required	Description
Connection	Yes	The Brightspot connection whose content model the script reads. Nothing the script does with content types works until this is set.
Language	Yes	The script language and its source code.
Description	No	A note describing what the script does, for easy identification.
Output Type	No	The shape of the value the script returns, so later steps can reference its fields.
Auto-generate Output Type	No	Infer the output type from the script's result on the last run, instead of declaring it by hand. Hidden once an output type is set. Not suited to a differences map, whose keys are record ids from that one run.

Script context

The same two values a Script step gets—payload for the preceding step's output and input for the values you mapped in—plus the dari object. The value the script returns becomes the step's output.

The plain Script action has no dari object; it is only available where a connection supplies a content model.

Output

If an output type is declared, the step exposes its fields. A value with no fields to expose—a scalar, a list, or an Object declared with no fields—is offered whole under payload. With no declared type, the output shape is unknown to later steps until the script runs.

A script that builds content typically ends with the differences map a Content action Save takes, which you then map into that step's Differences field. Declare that as an Object with no fields—its keys are record ids, so there is nothing to name—and it is offered under payload. See Returning a value.

Limits

The same ceilings as the Script action. Reading the content model costs one call to the connected CMS the first time a script names a type; the result is cached, so repeated runs do not pay it again.

Content Fetch action

Reads one piece of content from a Brightspot CMS—by content id, or by a field the type uses as a unique key.

Field	Required	Description
Connection	Yes	The Brightspot connection to read from.
Lookup Field	No	The field to match on. Leave blank to fetch by content id; name an indexed unique field (slug, an external id) to fetch by that instead.
Lookup Value	Yes	The value the lookup field must equal—a content id when Lookup Field is blank.
Content Type	No	Required for any lookup field other than the content id. Optional when fetching by id, where it narrows the fetch—content of any other type reports as not found.

There is one addressing, not two: the content id is a field like any other, so fetching by id is this step with Lookup Field left blank. Only the content id is unique across every type, which is why anything else needs a Content Type to search within.

Output

found, plus contentId, contentTypeId, contentTypeName, label and contentValues when something matched. Nothing matched leaves those absent rather than empty, so check found first.

Finding nothing by field is a normal result, not a failure. The step completes with found set to false, so a later step can create what was missing. Fetching by id is different—an id names content that is supposed to be there, so nothing at it fails the step.

Matching more than one record fails. The field is being used as a key, and picking one of several would act on an arbitrary record. Use Content Query when you want every match rather than exactly one.

Why this is a separate step

Every Content action operation reports the content it acted on—a Save that created names what it created, just as one that updated names what it changed. A read by unique field cannot promise that: nothing matched is a legitimate answer with no content to name.

The Content action's own Fetch operation is still there, deprecated, reading by id only. A miss by id fails, so it never produces the outcome that motivated the split—which is why it can stay for the automations that already use it. Anything needing a natural key belongs here.

Upserting without a branch

1. Content Fetch the Article whose slug is the one you have.
2. A Content Script builds from payload.contentValues when payload.found, and from scratch when it doesn't.
3. Content action → Save with a Content Type and Create If Missing, no target.

Content Query action

Resolves a query or a saved work stream to a list of content, to drive an automation across a set of items instead of a single event. Wire its results output into a Loop to process every match. Shown in the picker as Content Query, under Integration Actions. Requires a Brightspot connection.

Read-only, so a Content Query runs unchanged under a dry run—it always previews the real result set and count.

Fields

Field	Required	Description
Connection	Yes	The Brightspot connection to query.
Source	Yes	Where the content list comes from—Custom Query or Work Stream (see below).

Sources

Custom Query builds the list from a content type and optional filters:

Field	Required	Description
Site	No	Restrict the query to one site. Defaults to the connection's site when it pins exactly one, otherwise every accessible site.
Content Type	Yes	The type of content to query.
Predicate	No	How to narrow the type—Match Fields or Query Expression (see below). Leave unset to match every item of the type.
Max Results	No	Caps how many items are returned and iterated. Defaults to 100; the CMS caps it at 1000.

Match Fields builds a predicate from field conditions in the editor:

• Match—how to combine the conditions: All, Any, or None.
• Conditions—a list of Condition clauses (Field, Operator, Value) and nested Groups, each with its own Match and conditions, so you can express a and (b or c). A condition's value accepts variables.

Query Expression is a raw query for filters the builder can't express—an operator outside the allowlist, or and/or/not combined with grouping:

Field	Required	Description
Expression	Yes	A predicate expression using ? placeholders for values, e.g. headline contains ? and (cms.content.publishDate > ? or featured = ?). Supports and, or, not, parentheses, ?0/?1 positional binding, and keywords like missing.
Values	No	Values substituted for the ? placeholders, in order. Each accepts variables. A note warns when the count doesn't match the expression's placeholders.

Work Stream runs across a saved, progress-tracked CMS work stream:

Field	Required	Description
Work Stream	Yes	The work stream to run across.
Include Completed	No	By default only items not yet completed in the work stream are returned, so a re-run picks up where the last one left off. Turn on to return every item regardless of completion.
Max Results	No	Caps how many items are returned and iterated. Defaults to 100; the CMS caps it at 1000.

Output

results—a list of matched content, each a summary with its id, type, and label. totalCount and truncated report the full match count and whether Max Results cut the list short. With a Work Stream source, the output also identifies the work stream, so a later step's Complete Work Stream Item operation can reference it.

Email action

Sends an email to one or more recipients. Shown in the picker as Email, under Notification Actions. Needs no connection; delivery is configured by an administrator.

Fields

Field	Required	Description
To	Yes	The recipient email addresses. Accepts variables.
Subject	No	The subject line. Accepts variables.
Body	No	The message body, as rich text with basic formatting. Accepts variables.

Recipients who have opted out are skipped, and each message includes an unsubscribe link.

Output

Field	Description
sent	Addresses the message was sent to.
failed	Addresses that failed, each with a reason.
skipped	Addresses that were skipped (for example, opted out), each with a reason.

GitHub action

Runs one operation against a GitHub repository. Shown in the picker as GitHub, under Integration Actions. Requires a GitHub connection.

Fields

Field	Required	Description
Connection	Yes	The GitHub connection to use.
Repository	Yes	The repository to act on, as organization/repository.
Operation	Yes	What to do (see below).

Operations

Group	Operations
Pull requests	Create Pull Request, Get Pull Request, Update Pull Request, Merge Pull Request, Submit Pull Request Review, Add Reviewers.
Issues	Create Issue, Get Issue, Update Issue.
Issues and pull requests	Add Comment, Modify Assignees, Modify Labels.
Branches	Create Branch, Get Branch, List Branches, Delete Branch.
Files and commits	Get File Contents, Create or Update File, Create Commit, Create Commit Status.
Releases	Create Release.
Workflows	Trigger Workflow.

Each operation takes the inputs it needs—a pull request or issue number, a branch name, a file path and contents, and so on. Many text inputs accept variables.

Output

The result of the operation—for example, the created or fetched pull request, issue, branch, file, or commit. Some operations (such as merge or label changes) return no payload.

HTTP Request action

Sends an HTTP request to any URL. Shown in the picker as HTTP Request, under General Actions. Needs no connection.

Fields

Field	Required	Description
Method	Yes	The HTTP method: GET, POST, PUT, PATCH, DELETE, HEAD, or OPTIONS.
URL	Yes	The request URL. Accepts variables.
Query Parameters	No	Name/value pairs appended to the URL; each can be enabled or disabled.
Headers	No	Request headers; each can be enabled or disabled.
Body	No	The request body. Available for methods that support one (POST, PUT, PATCH).
Auth	No	Optional authentication applied to the request.
Follow Redirects	No	Whether to follow redirects. On by default.
Fail On Error Status	No	When on, a non-success status fails the step so the flow can follow its error path. Off by default.

Advanced

Field	Description
Connect Timeout (ms), Read Timeout (ms)	Per-request timeouts.
Response Destination	How the response body is captured: Discard (status only), Headers Only, Inline (body in the payload), Storage (stream to storage), or Automatic (inline, spilling to storage if too large).
Inline Response: Max Size, Storage Response: Max Size	Size limits for the inline and storage tiers.
Resilience	Opt-in retry, timeout, and circuit-breaking for this step. Left unconfigured, a failure is terminal as before. Fields: Max Retries (0 disables), Initial Retry Delay, Backoff Multiplier, Max Retry Delay, and Jitter (randomize each delay by ±50% so many failing runs don't retry in lockstep); Attempt Timeout (fails a single attempt that runs too long, independent of retry); Enable Circuit Breaker with a Failure Threshold and Open Duration, so a struggling endpoint fails fast instead of being hammered once it has failed repeatedly. Retries are durable—a long backoff survives a restart—and each attempt is recorded, so the step's history shows every retry.
Dry Run: Outbound HTTP	Overrides the site-wide policy for which methods this step sends during a dry run—None, Safe Methods Only, or All Methods. Leave unset to inherit the site setting.

Output

Field	Description
status, statusText	The HTTP status code and text.
headers	Response headers.
cookies	Set-Cookie values.
body	The raw body (inline and automatic modes).
json	The parsed body, when the response is JSON (inline and automatic modes).
storageItem	A reference to the stored body (storage and automatic modes).

For safety, requests to private and loopback network addresses are blocked.

Jira action

Runs one operation against a Jira project. Shown in the picker as Jira, under Integration Actions. Requires a Jira connection.

Fields

Field	Required	Description
Connection	Yes	The Jira connection to use.
Project	Yes	The Jira project to act in.
Operation	Yes	What to do (see below).

Operations

Operation	Key inputs
Create Issue	Issue type, summary, optional description, assignee, priority, labels, custom fields.
Get Issue	Issue key.
Update Issue	Issue key, plus the fields to change.
Assign Issue	Issue key, assignee (blank to unassign).
Transition Issue	Issue key, transition, optional comment.
Add Comment	Issue key, comment body.
Search Issues	A JQL query, with optional paging and field selection.
Delete Issue	Issue key; option to delete subtasks.
Add Worklog	Issue key, time spent, optional comment and start time.
Link Issues	Two issue keys, link type, optional comment.
Add Watcher	Issue key, account.
Remove Watcher	Issue key, account.

Output

The result of the operation—for most operations the affected issue or comment; for Search Issues, the matched issues with paging information.

Log action

Writes a message to the run's execution log, then continues. Shown in the picker as Log, under General Actions. Needs no connection.

Fields

Field	Required	Description
Message	No	The line written to the execution log. Mix literal text with variables to record what a value holds at that point in the flow.
Variables	No	Upstream values recorded with the step for inspection, without being written into the message line. Use for complex objects, which read poorly inline—a variable in the message resolves to a flat string.

The message lands in the step's own execution log, never in the server log, so a Log step can stay in a live automation as a lightweight trace of what a value held—without the weight of a Script action.

Output

None. A Log step is transparent: it adds nothing of its own, and later steps keep referencing earlier outputs unchanged.

OpenAPI action

Calls an operation described by an OpenAPI specification. Shown in the picker as OpenAPI, under General Actions. Needs no connection of its own.

Fields

Field	Required	Description
Spec URL	Yes	The URL of the OpenAPI specification. Validated as you enter it.
Operation	Yes	The operation to call, chosen from the operations the spec defines.

Once you pick an operation, the action adds a field for each of that operation's path, query, and header parameters, and for its request-body properties. Many of these accept variables.

On the Advanced tab, Dry Run: Outbound HTTP overrides the site-wide policy for which methods this step sends during a dry run—None, Safe Methods Only, or All Methods. Leave unset to inherit the site setting.

Output

The operation's response, shaped by the response schema the specification defines for it.

Remote AI Agent action

Runs an AI agent through a connected Brightspot CMS—that CMS's own agent does the work with its tools. Shown in the picker as Remote AI Agent, under AI Actions. Supports human-in-the-loop.

Fields

Field	Required	Description
Connection	Yes	The Brightspot connection that runs the agent.
Persona	No	An author persona from the connected CMS whose writing style the agent adopts.
Prompt	Yes	The natural-language task for the agent. Accepts variables, so it can work on the trigger's data and earlier results.
Payload Type	No	An output shape the agent populates as structured data, in addition to its message.
Human in the Loop	No	Opt-in. Set it to let the agent pause and ask a person before finishing, and choose the Providers the question is pushed to (for example, Slack)—every request is also answerable from the AI Approvals inbox. Left unset, the agent must finish on its own.

The node's Display-tab Description, when left blank, falls back to the start of the prompt.

Human-in-the-loop

When Human in the Loop is set, the agent can pause to ask a person for input—a choice or free text. The step waits until the request is answered, then the agent resumes with the answer.

Output

Field	Description
message	The agent's text response.
payload	The structured result, when a payload type is set.

Script action

Runs a script in a sandbox. Shown in the picker as Script, under General Actions. Needs no connection.

Fields

Field	Required	Description
Language	Yes	The script language and its source code.
Description	No	A note describing what the script does, for easy identification.
Output Type	No	The shape of the value the script returns, so later steps can reference its fields.
Auto-generate Output Type	No	Infer the output type from the script's result on the last run, instead of declaring it by hand. Hidden once an output type is set.

Give the node a Display-tab Description for identification—see Building automations.

Script context

The script can read two values:

• payload—the output of the preceding step. Not defined at all when the preceding step produced nothing, so a script that may run in that position checks typeof payload !== 'undefined' rather than payload?.field; optional chaining does not survive an undefined name.
• input—the values you mapped into the step.

The value the script returns becomes the step's output.

Output

If an output type is declared, the step exposes its fields. A value with no fields to expose—a scalar, a list, or an Object declared with no fields—is offered whole under payload. With no declared type, the output shape is unknown to later steps until the script runs.

Limits

Scripts run in a sandbox 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 scripts at once and none of them should be able to slow the others down. Script steps are intended for transforming data, and the defaults are set 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 about 250,000 statements, under a tenth of a second, and under 4 MB of memory.

Cross a ceiling and the step fails with a message naming the one you crossed, so you can tell which value is in the way. Your administrator can change any of these. The two memory ceilings and the CPU ceiling depend on how the server is set up—an administrator can tell you which apply to your deployment—but the message you get 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.

Slack Message action

Posts a message to a Slack user or channel. Shown in the picker as Slack Message, under Notification Actions. Requires a Slack connection.

Fields

Field	Required	Description
Connection	Yes	The Slack connection to post through.
Recipient	Yes	A user or channel to message. Accepts variables.
Message	No	The message, as rich text with basic formatting. Accepts variables and is converted to Slack formatting.

Output

Field	Description
recipient	The recipient the message was sent to.
channel	Slack's resolved channel ID.
ts	Slack's message timestamp, usable to thread replies.

Sleep action

Pauses the flow for a set duration, then continues. Shown in the picker as Sleep, under General Actions. Needs no connection.

Fields

Field	Required	Description
Sleep For (ms)	Yes	How long to pause, in milliseconds.

While paused, the run waits without consuming resources, then resumes and passes its incoming payload through unchanged.

Output

None.

note

A sleep longer than the automation's execution timeout is flagged in the editor.

Teams Message action

Posts a message to a Microsoft Teams channel over a connected bot. Shown in the picker as Teams Message, under Notification Actions. Requires a Microsoft Teams connection.

TODO screenshot

The Teams Message form—Connection, the cascading Team and Channel pickers, and a rich-text message with a variable chip.

Fields

Field	Required	Description
Connection	Yes	The Microsoft Teams connection to post through.
Team	Yes	The team to post to, chosen from a picker. Limited to the connection's allowed teams when it curates a subset.
Channel	Yes	The channel within the selected team, chosen from a cascading picker (standard channels only).
Message	No	The message, as rich text limited to Teams-representable formatting (bold, italic, link, lists). Accepts variables and is converted to an Adaptive Card.
Test Recipient Override	No	On the Advanced tab. During a Dry Run, redirects the post to a test team/channel instead of the real destination.

Recipient selection is picker-only—you pick display names, never raw IDs. The pickers stay empty until the connection's administrator grants Microsoft Graph admin consent.

Output

Field	Description
channel	The channel ID the message was posted to.
conversationId	The Bot Framework conversation ID the message was posted to.
activityId	The ID of the created message activity.

Stop with Error action

Deliberately fails the run when the flow reaches it. Shown in the picker as Stop with Error, under General Actions. Needs no connection.

Place it on a path that should never be taken—the false branch of a condition guarding an expected value—so an unexpected outcome becomes a visible failed run instead of a silent success.

Fields

Field	Required	Description
Error Message	No	The message recorded on the failed run. Accepts variables, so it can include the unexpected value. Left blank, a standard message is recorded.

The failure is unhandled by design—it does not follow an error path—so reaching this node always fails the run.

Output

None. The node always fails, so later steps never read from it.

Conditions

Routing the flow. See Conditions and branching.

AI Judgment condition

Routes the flow based on an AI agent's answer to a yes/no question. Shown in the picker as AI Judgment, under General Conditions. Routes to true when the agent answers yes, otherwise to false.

Fields

Field	Required	Description
Template	No	A reusable agent from the Agents catalog whose guidelines the judgment applies—for example, a brand-aware evaluator.
Context	No	Framing for the judgment—the criteria or background the AI should weigh, such as "On-brand means a positive tone, no politics, and lifestyle topics."
Question	Yes	The yes/no question that decides the route. Accepts variables, so it can ask about the trigger's data and earlier results.
MCP Servers	No	Tool sources the agent may call to inform its judgment—for example, a Brightspot environment, to check whether matching content already exists. Leave empty to judge from the question alone.

Deciding a route must not change anything, so the agent is only ever offered read-only tools—in a live run as well as a dry run. Mutating work belongs in an AI Agent action after the branch.

Output

The incoming payload, passed through unchanged on the chosen path. The agent's reasoning for its answer is written to the step's log, so the branch choice is explainable afterward.

Expression condition

Routes the flow based on a boolean expression you build. Shown in the picker as Expression, under General Conditions. Routes to true when the expression is true, otherwise to false.

Fields

Field	Required	Description
Expression	Yes	The boolean expression to evaluate, built from the comparisons and combinators below.

Comparisons

A comparison tests one or two values, each a variable or a literal.

Operator	Tests whether…
Equals (==)	The two values are equal.
Not Equals (!=)	The two values differ.
Greater Than (>), Less Than (<)	One number is greater / less than another.
Greater Or Equal (>=), Less Or Equal (<=)	One number is at least / at most another.
Contains	The first value contains the second.
Matches Regex	The value matches a regular expression.
Is Empty, Is Not Empty	A single value is empty / not empty.
Is Truthy, Is Not Truthy	A single value is truthy / not truthy.

Combinators

Combinator	True when…
All Of	Every condition inside it is true (AND).
Any Of	Any condition inside it is true (OR).
Not	The condition inside it is false.

Combinators can nest, so you can build expressions of any depth. The editor shows a readable preview as you build.

Output

The incoming payload, passed through unchanged on the chosen path.

Random (A/B Split) condition

Routes the flow randomly, by a percentage you set—useful for A/B tests. Shown in the picker as Random (A/B Split), under General Conditions.

Fields

Field	Required	Description
True Percentage	Yes	The percentage of runs that route to true (0–100). The rest route to false. Defaults to 50.

Output

The incoming payload, passed through unchanged on the chosen path.

Script condition

Routes the flow based on a script's result. Shown in the picker as Script, under General Conditions. Routes to true when the script returns a truthy value, otherwise to false.

Fields

Field	Required	Description
Language	Yes	The script language and its source code.

Script context

The script can read two values:

• payload—the output of the preceding step.
• input—the values you mapped into the step.

A returned value of null, false, zero, an empty string, or an empty collection routes to false; any other value routes to true.

Limits

The same sandbox and the same ceilings as the Script action.

Output

The incoming payload, passed through unchanged on the chosen path.

Loops

Repeating part of a flow. See Loops and iteration.

Loop

Opens a loop that repeats the body between it and its paired Loop End once for each item in a list. Shown in the picker as Loop, under Control. Adding a loop scaffolds the Loop and Loop End pair together.

Fields

Field	Required	Description
Source	Yes	The list to iterate over, taken from an upstream variable that produces an array.
Mode	Yes	Whether iterations run serially (one after another) or in parallel. Serial iterations can see the previous iteration's results; parallel iterations run independently.
Failure Policy	No	What happens when an item's body fails: fail fast stops the loop on the first failure; best effort records it and continues.

Output

Inside the loop body, the Loop node's output is the current item. Reference its fields to act on each item in turn.

Loop End

Closes a loop and converges its body. Shown in the picker as Loop End, under Control. It is paired with a Loop node and is normally added together with it.

Fields

Field	Required	Description
Collect Results From	No	Gather one value from every iteration into the loop's results output—a body node's whole output, or one of its fields. Leave unset to emit only the run stats. To combine several body nodes, funnel them through one node first and collect that.

Output

A summary of the loop:

Field	Description
count	The number of iterations.
successCount	How many iterations succeeded.
failedCount	How many iterations failed.
results	Present only when Collect Results From is set. One entry per iteration, in order, shaped as the collected value—skipping any iteration that didn't complete.

A later step can branch on count/successCount/failedCount to react to partial failures, or consume results as the whole set the loop processed—for example, feeding every iteration's output into a single downstream AI action.

Connections

Authenticated links to external systems. See Connections for how to create one.

Brightspot connection

Connects to a Brightspot CMS instance so the Content trigger and Content action can act on it. Shown in the picker as Brightspot. Authenticates with OAuth 2.0, configured automatically from the instance's base URL. The target CMS must have the Esca server module installed—an administrator task—before connecting works.

Fields

Field	Required	Description
Instance Name	No	A memorable name for the instance.
Base URL	Yes	The base URL of the Brightspot instance. Normalized to scheme, host, and port on save.
Basic Auth → Username, Password	No	HTTP Basic credentials for reaching a protected lower environment that sits behind a gateway. Separate from the OAuth sign-in below.

Authentication

Authentication uses OAuth 2.0. The connection discovers the instance's OAuth endpoints from the base URL and registers itself automatically—you do not enter client credentials. Click Connect and sign in to the target CMS to authorize access. Once connected, the connection shows the signed-in user's name and email.

Custom OAuth connection

Connects to any OAuth 2.0 service, for use with the HTTP request and OpenAPI actions. Shown in the picker as Custom OAuth.

Fields

Field	Required	Description
Name	Yes	A name for the connection.
Auto-config Input	No	Paste a discovery URL (RFC 8414 / RFC 9728) or an OpenAPI 3 oauth2 security-scheme fragment. On save, the connection fills in the endpoints, scopes, and—where the provider supports it—client credentials. Leave blank to configure the fields by hand.

Authentication

The embedded Custom OAuth 2.0 authentication exposes the full OAuth configuration, either filled in by auto-config or entered manually:

Field	Required	Description
Client ID	Yes	The OAuth client ID.
Client Secret	No	The client secret (omit for public clients).
Authorize URL	Yes	The provider's authorization endpoint.
Token URL	Yes	The provider's token endpoint.
Revoke URL	No	The revocation endpoint, if the provider offers one.
Scopes	No	The scopes to request.
Scope Delimiter	No	How scopes are joined. Defaults to a space.
Token Endpoint Auth Method	No	How credentials are sent to the token endpoint. Defaults to HTTP Basic.
Refresh Rotates	No	Whether the provider issues a new refresh token on every refresh.
Resource	No	An RFC 8707 resource indicator, sent on authorize and token requests.
Use PKCE	No	Use PKCE (S256). On by default; required by OAuth 2.1. Disable only for legacy servers that reject it.
Extra Authorize Params, Extra Token Params	No	Additional provider-specific parameters.

After configuring, click Connect to authorize.

GitHub connection

Connects to GitHub so the GitHub trigger and GitHub action can use it. Shown in the picker as GitHub.

Fields

Field	Required	Description
Name	Yes	A name for the connection.
Auth	Yes	The authentication method—Personal Access Token or App Installation.

Authentication

Personal Access Token

Field	Required	Description
Token	Yes	A GitHub personal access token.

Personal access tokens are tied to a user account and stop working if that account is deactivated.

App Installation

Field	Required	Description
App ID	Yes	The GitHub App's ID.
Installation ID	Yes	The installation ID for the organization the app is installed in.
Private Key (PEM)	Yes	The app's RSA private key in PKCS#8 PEM format.

An app installation is tied to an organization rather than a person, so it survives personnel changes—the right choice for a shared connection. If GitHub gives you a PKCS#1 key (beginning -----BEGIN RSA PRIVATE KEY-----), convert it to PKCS#8 first.

Both methods use stored credentials, so there is no connect-and-redirect step.

Jira connection

Connects to a Jira site so the Jira trigger and Jira action can use it. Shown in the picker as Jira.

Fields

Field	Required	Description
Name	Yes	A name for the connection.
Site URL	Yes	The Jira site URL, for example https://your-org.atlassian.net.
Auth	Yes	The authentication method—API Token or OAuth 2.0 (3LO).

Authentication

API Token

Field	Required	Description
Email	Yes	The email address of the Atlassian account that owns the API token.
API Token	Yes	A token generated at id.atlassian.com under Security → API tokens.

A service account is recommended over a personal account for production, so the connection does not break when a person's access changes.

OAuth 2.0 (3LO)

Field	Required	Description
Client ID	Yes	The client ID of your Atlassian OAuth 2.0 (3LO) app.
Client Secret	Yes	The app's client secret.

After entering the credentials, save and click Connect to authorize the app. OAuth is required for triggers that register their Jira webhooks automatically, because Atlassian limits the dynamic-webhook endpoint to OAuth apps.

note

The connection's authentication method and site URL cannot be changed while OAuth is connected or while registered webhooks exist.

Microsoft Teams connection

Connects to an Azure Bot / Entra application so the Teams Message action can post to Teams channels. Shown in the picker as Microsoft Teams. Bot-only—there is no webhook option.

TODO screenshot

The Microsoft Teams connection form—Name, the Auth cluster (Tenant ID, Client ID, Client Secret), and Allowed Teams—with the setup checklist, consent link, and app-package download note.

Fields

Field	Required	Description
Name	Yes	A name for the connection.
Auth → Tenant ID	Yes	The Entra directory (tenant) ID.
Auth → Client ID	Yes	The Entra application (client) ID. This is also the bot ID.
Auth → Client Secret	Yes	The Entra client secret. Stored encrypted and never logged. Entra caps secret lifetime at 24 months—rotate before expiry.
Allowed Teams	No	The teams this connection may target. Leave empty to allow any team in the tenant; when set, the action's team picker is limited to these teams. Populating it requires Graph admin consent.
Service URL	No	On the Advanced tab. The Bot Connector URL messages are sent through. Leave blank for the global Teams cloud.
Inbound Issuer	No	On the Advanced tab. The issuer inbound Teams replies must be signed by. Leave blank for the documented default.
Inbound JWKS URL	No	On the Advanced tab. Where Microsoft's signing keys are fetched from to verify inbound replies. Leave blank for the documented default.

The three Advanced fields exist for one case: a bot registered in a sovereign or government Microsoft cloud, which uses different endpoints from the public one. Leave all three blank otherwise—each connection resolves its own, so connections in different clouds can coexist. Changing the inbound two incorrectly stops Teams replies from being accepted while outbound posting keeps working.

Authentication

Credential-based—there is no Connect button. Enter the tenant ID, client ID, and client secret and save; the connection is usable immediately. The team and channel pickers additionally require an administrator to grant admin consent for two read-only Microsoft Graph permissions (Team.ReadBasic.All, Channel.ReadBasic.All), and the bot must be installed into each target team via the generated app package. For registering the app, granting consent, and installing the package, see Setting up the Microsoft Teams connection.

Answering approvals from a Teams card needs one further step—the Azure Bot's messaging endpoint must point at Esca. See Enable approvals in Teams.

Microsoft Teams human-in-the-loop provider

Presents an agent's human-in-the-loop question as an interactive card in a Teams channel, and updates that card in place once the request is answered. Selected on an agent action node, alongside any other providers you want notified. Shown in the picker as Microsoft Teams.

TODO screenshot

A Teams channel showing an interactive request card—question, agent context, schema-derived inputs, and a Submit button—next to the same card after resolution, reading "Answered by … at …".

Fields

Field	Required	Description
Connection	Yes	The Microsoft Teams connection to post through.
Team	Yes	The team containing the target channel. Drawn from the connection's Allowed Teams when a subset is set, otherwise from every team in the tenant.
Channel	Yes	The channel where the question is posted. Populated from the selected team's standard channels.

Recipient selection is picker-only, exactly as it is for the Teams Message action—you select display names and never type or paste a raw ID.

Behavior

The card opens with the automation's name and a one-line note that an automation has paused and needs input, followed by links to the automation and to the step that is waiting—so whoever receives it can see what asked, and go look, without hunting for it in Esca.

Below that is the agent's question. The card's inputs are generated from the shape of that question, so a yes/no confirmation, a choice among options, and a multi-field form each render appropriately. A field the card cannot represent faithfully falls back to a text box rather than being dropped.

Last in the card is a collapsible Details section holding the agent's most recent response—the summary it wrote just before pausing to ask. Click the row to expand it. Formatting in that summary, including lists, is preserved. Very long responses are clipped.

The agent's individual tool calls are not shown. The response is what explains the question, and tool arguments can contain content that does not belong in a channel.

When anyone answers—in Teams, in another channel, or from Esca's own pending-requests surface—the Teams card is replaced by a resolved version showing the answer and who gave it, so a stale card never keeps inviting a second submission.

Two behaviors worth knowing:

• Progress is not streamed. Unlike Slack, the Teams card appears when the agent asks its question rather than updating live as the agent works. Teams has no streaming primitive for cards, and repeatedly rewriting one runs into platform rate limits. The Details section is therefore a snapshot taken at the moment the agent paused, not a live feed.
• The links depend on the CMS having a configured default tool URL. Without one, the automation and step are still named on the card but are not clickable.
• In a dry run, the card is posted to the channel from the automation's Teams test override if one is configured. With no override the Teams post is skipped entirely and the request is answered from within Esca—so a dry run never messages a real channel by accident.

If the Azure Bot's messaging endpoint is not configured, the card posts but its Submit button cannot reach Esca. See Enable approvals in Teams.

Slack connection

Connects to a Slack app so the Slack Message action can post messages and human-in-the-loop requests can be answered in Slack. Shown in the picker as Slack.

Fields

Field	Required	Description
App Name	No	A memorable name for this Slack app. Falls back to the workspace name once connected.
Auth → Client ID, Client Secret	Yes	The credentials of your Slack app, used for the OAuth install.
Signing Secret	No	The app's signing secret, used to verify Slack's interactive callbacks (such as approval button clicks). Found in the Slack app console under Basic Information → App Credentials.
Enable Channel List	No	Enables channel auto-complete in the recipient picker. Requires the app's channels:read scope to be approved.

Authentication

Enter the client ID and secret, save, then click Connect to install the app into your Slack workspace. Once installed, the connection can post as the app's bot. For creating and configuring the Slack app itself—scopes, redirect URL, and interactivity—see Setting up the Slack connection.

MCP servers

Tool sources for the AI Agent action and the AI Judgment condition, managed on the Connections page. See MCP servers for how to add one. Every server has a Name, which both labels it and identifies its tools to the agent.

Brightspot MCP server

The MCP endpoint of a Brightspot CMS. Shown in the picker as Brightspot. An MCP server is separate from a Brightspot connection—it authenticates against the CMS's MCP endpoint directly, matching how an administrator configured that endpoint.

Fields

Field	Required	Description
Name	Yes	Identifies the server and its tools to the agent.
MCP Endpoint URL	Yes	The full URL the CMS serves MCP at, for example https://cms.example.com/mcp.
Auth	Yes	OAuth or API Key, matching how the endpoint is configured. The API key is sent as the X-API-Key header.

Authentication

With OAuth, everything is configured automatically: click Connect, sign in to the CMS, and authorize access—endpoints are discovered from the URL and a client is registered for you. With API Key, paste the key and save; there is no connect step.

Custom MCP server

Any remote MCP server, reached by URL. Shown in the picker as Custom. A Brightspot MCP endpoint can also be reached through this type, but the Brightspot server type is the first-class option.

Fields

Field	Required	Description
Name	Yes	Identifies the server and its tools to the agent.
Remote MCP Server URL	Yes	The URL the server is reached at.
Requires OAuth	No	Enable when the server requires OAuth. Leave off for a public server—no credentials are sent.
Client ID	No	Shown when Requires OAuth is enabled. Leave blank to register a client dynamically at connect time; set it only when the server requires a pre-registered client.
Client Secret	No	Shown when Requires OAuth is enabled. The secret for the pre-registered client, if any.

Authentication

A public server needs nothing beyond its URL. For an OAuth server, enable Requires OAuth and click Connect—the OAuth endpoints are discovered from the URL, and unless you supplied a pre-registered client ID and secret, a client is registered dynamically as part of the flow.