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. 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.
Operation	Yes	What to do (see below).

Operations

Operation	Description	Extra fields
Fetch	Read the target content.	—
Publish	Publish the target content.	—
Save	Save changes to the target content.	Fields—a JSON object of field name to value, applied directly to the target content. Embedded Objects—an advanced list of field changes for embedded objects inside the content, one entry per object, each holding the object's id and its own JSON object of field name to value. 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.

A Save fails—rather than reporting success—when a change targets no content actually present (a misspelled or stale id) or changes no stored value.

Output

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

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.
• 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 scalar or list value is exposed under result). 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.

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.

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.