Building automations

You build an automation in the flow editor—a canvas where you place nodes and connect them into a flow. Open it by clicking New Automation on the Automations page, or by clicking an existing automation's name to edit it.

This page covers the editor itself. For what the individual steps do, read the concepts for the ideas behind them, and the built-in nodes and integrations catalogs for every step and connection type, field by field.

Drafting an automation with AI

You don't have to start from an empty canvas. On the Build page, describe the automation you want in plain language—for example, "When an article is published, summarize it and post the summary to Slack"—and Esca drafts a flow with the triggers, conditions, and actions to match. The draft is saved for you and opens in the editor, but it is created safely: it arrives as a draft, turned off, so nothing it contains can fire until you have reviewed it, turned it on, and published it. That holds even if you stop the drafting partway—whatever had been built by then is kept, an unpublished draft turned off, rather than discarded.

Drafting runs on your default AI model, as does the Esca assistant inside the editor, and neither is available when no model is configured. See AI agents and models.

Starting from a template

Instead of building from an empty canvas, the Templates page opens a catalog of starter flows—the ones that ship with Esca Automations, plus any you have saved from your own automations (see Saving an automation as a template).

Templates come in three kinds, and the kind is how you navigate the catalog rather than a filter you apply to it—only one kind is on screen at a time. The page opens on a chooser asking What are you starting with?, with a card per kind explaining what it is and how to tell whether you want it, and a fourth card for the templates saved here:

• Examples—single-node lessons showing how one node is configured. A lesson to read before you build your own, not something to ship.
• Recipes—reusable fragments that solve one common sub-task. A recipe is a piece of an automation rather than a whole one: insert it into a workflow you are already building, or start one here and it adds a trigger to get it going.
• Workflows—complete, production-ready automations to use as-is or adapt. A workflow brings its own trigger, so you can turn it on as-is.

Each card carries a count of the templates in that kind. Click Browse on one to drill into it; the cards become a tab strip so you can move between kinds without going back. Each kind has its own address, so you can bookmark or share a link that opens straight into it, and ← All kinds returns to the chooser.

Inside a kind, a search box (matching name, description, tags, and node types) and a node type dropdown grouped into Triggers, Conditions, and Actions narrow what is on screen, with no reload. The counts on the tabs update as you type, so a search that only matches another kind is still visible from the one you are in.

A fourth card, Saved, holds the templates saved from this site's own automations, of every kind. Because a site can save any number of them, this silo loads a page at a time as you scroll, and its search box asks the server rather than hiding cards, so it always answers for the whole site. Each saved card wears a badge naming its kind—Workflow, Recipe, or Example—since the silo mixes them.

A template card shows the template's name, its description, and one icon per distinct node type the template uses (hover an icon to name it), with two actions: Preview opens a read-only popup of the template's graph, and Use template opens the flow editor pre-loaded with the template's nodes as an unsaved automation—nothing is created until you save it. Where you are using a mouse or trackpad, the two actions appear when you point at the card. A card carries no kind badge, since every card on screen is the kind you are browsing, and it carries no tags either—tags are a filter on the in-editor recipe picker rather than something a catalog card shows, though the search box still matches them.

Template	Kind	What it does
On-Demand AI Summary	Workflow	An on-demand trigger feeding an AI agent that summarizes the supplied content.
AI Draft & Brand Review	Workflow	Generates a draft with the Content Generation agent, then revises it for brand voice.
Brightspot Content Workstream	Workflow	Runs an AI agent across every item in a Brightspot work stream, applying the work stream's instructions to each and marking items complete as it goes.
Extract a Field from Each Item	Recipe	Turns an array of objects into a flat array of one field's values.
Collect Array Values into One	Recipe	Reduces an incoming array to a single value—for example, the sum of its numbers.
Twilio: Send a Text Message	Recipe	Sends an SMS through Twilio's API, reading your account details from shared variables and secrets set up once; only the recipient and message text are wired per node.
Log: Write a Message	Example	Writes a message to the run log with the Log action—ready to run right away.
Script: input & payload	Example	Shows how a Script node reads its incoming payload and input mappings, and how its last expression becomes the output.

A Recipe is also available without leaving the automation you're building: click + on an edge and select Recipe… to open a full-screen recipe picker—the same card layout and node-type filter as the catalog, narrowed to recipes, plus a row of tag pills to toggle—and splice its nodes directly into the flow, wired in at that point.

Saving an automation as a template

Any saved automation can become a template of your own. Open the editor's more-options menu and click Save as Template: a form opens over the canvas, prefilled with the automation's name and description, where you choose the kind—Workflow, Recipe, or Example—and add tags. The tag field offers the tags already in use across the catalog and accepts a new one typed in, so a topic that already exists keeps its spelling, and with it its filter. A template's name has to be unique within the site; the form says so if the one you picked is taken.

What is captured is the automation as it was last saved, so the menu item is grayed out while the canvas has unsaved changes, the same way Run is. The capture is the same portable definition Export downloads—nodes, edges, notes, variables, and settings—with one difference: secrets are left out entirely, values and names alike. A field that referenced one shows a stale-reference warning in the automation you start from the template, which is your cue to pick or create the secret that automation should use. Connections are captured as they stand, so a template used in the site that saved it arrives already connected.

The template appears in the catalog's Saved silo, newest first, with a badge naming its kind and an Edit button—where its name, description, kind, and tags are corrected, and where it is deleted. Deleting a template leaves every automation already made from it untouched. A saved Recipe is also offered in the editor's recipe picker beside the built-in recipes; the picker shows the hundred most recently saved, and the rest are still in the catalog.

A saved Recipe is treated as the fragment a recipe is meant to be. Inserting it from an edge's + menu leaves the trigger it was captured with behind, so the automation you are inserting into keeps its own entry point; choosing Use template to start a new automation from it brings that trigger along, so the result can run as it stands. Because a recipe is spliced in at one point, save one from an automation with a single path in and a single path out.

The canvas

The canvas holds the automation's nodes and the edges between them. Pan by dragging the background and zoom with the controls in the corner. Every flow starts from a single trigger node on the left and follows its edges to the right.

Each node renders as a card: its icon and type, the name you gave it, and a short summary of its configuration—so a well-built flow reads at a glance without opening anything. To give a node a title and description of your own, open its configuration form and switch to the Display tab: a title appends to the node's type on the card ("Script - Fetch customer"), and a description becomes the card's first summary line, ahead of the automatic configuration summary.

The toolbar

The bar above the canvas carries the automation-level controls, left to right: the AI assistant toggle, the automation's name (click it to rename) with a pill saying what the record is (Draft, Published, Revision, or Archived), the Turn On/Turn Off toggle, the run button when the trigger supports manual runs, the validation indicator, settings, Save and Publish—or Edit, on a published automation—and the more-options menu.

Adding nodes

A new automation starts empty with a single Add node button in the center of the canvas.

• The first node must be a trigger. Click Add node and select Trigger, then choose a trigger type from the panel that opens.
• Later nodes are added on an edge. Point to the line leaving a node and click + (Insert node), then select Condition, Action, or Loop. The new node is inserted on that edge and wired automatically. The same menu also offers Recipe…, which splices a multi-node fragment in at that point instead—see Starting from a template.

Selecting Loop scaffolds a matched pair—a Loop node and a Loop End node—already connected. See Loops and iteration.

Configuring a node

Selecting a node type opens its configuration form in the panel on the right. The panel has two modes: a searchable, filterable list of types, and the selected type's form.

To configure a node:

1. Complete the form. Many fields accept variables—see Variables and secrets.
2. Click Done to commit the configuration. The node's card updates with a short summary of what you set.

To change a node later, click its edit (pencil) control to reopen the form. To discard a node, open the form and click Delete, or use the node's actions menu.

Connecting and branching

Edges define the order steps run in. Conditions and other routing nodes send the flow down different paths from their output handles—see Conditions and branching. A handle that already has a child still offers a +, revealed on hover or selection, so you can branch a second step off the same node without dragging a connection by hand.

Any node can also expose an error path. Enable error handling from the node's actions menu to add a separate output that the flow follows when the node fails, so you can handle failures instead of stopping the run.

Annotating the canvas

Sticky notes document a flow without becoming part of it—they never affect execution and never appear as a node. Open a node's actions menu and click Add note to create one anchored to that node, connected by a tether line; deleting the node leaves its notes on the canvas, no longer anchored. The canvas + menu offers the same Add note for a free-standing note not tied to any node. Either way, the note picks up the last color you used—click the swatch beside Add note to choose a different one before adding it.

Drag a note to reposition it or resize it from its handle. Double-click a note to open its form in the side panel, where you can give it a title, choose its color and font size, and format its text with a rich-text toolbar—bold, italic, underline, strikethrough, superscript/subscript, lists, links, inline code, and images. A note's text can also be selected and copied directly off the canvas, without opening its form—handy for lifting a variable or secret name a template's note tells you to create. To remove a note, select it and press Delete or Backspace.

Notes travel with the automation—duplicating it, saving it as a template, and exporting it all carry the notes along. In version history, moving or resizing a note counts as a layout-only change, not an edit.

Naming, validating, and saving

• Name—click the automation's name in the toolbar and type a new one. A new automation—including one started from a template—gets a default name that avoids colliding with an existing one by appending the lowest free number: a second automation started from the On-Demand AI Summary template is named "On-Demand AI Summary 2".
• Validation—the editor validates the flow as you build and flags structural problems, such as disconnected nodes or a loop that is not closed. The toolbar indicator reads Verified when the flow is sound and Invalid when it is not; fix the flagged issues before saving.
• Needs attention—separately, a field a node needs in order to run—but not to save—shows a note instead of blocking you, and the node's card carries a count of how many such fields remain unset. This lets you save a work-in-progress node (or one left empty by an import) and come back to it later, rather than forcing you to fill in every field before you can save anything.
• Settings—click the settings icon to open the automation's own settings, including automation-scoped variables and secrets, in the same side panel used for nodes and notes rather than a separate dialog. Click Done to stage your changes—they aren't saved yet—or Cancel to discard them; leaving with unstaged changes prompts you to confirm.
• Save—click Save. The editor does not save automatically. A new automation is assigned an identifier on first save, and it's what commits any settings staged with Done. Saving never changes what runs for real: a new automation is a draft until you publish it. See Publishing and run modes.
• Turn on—toggle Turn On to enable the automation. Enabling lets triggers that fire on their own—content events, schedules, and webhooks—start the automation. An on-demand automation runs when you start it manually, whether or not it is enabled.

Publishing and run modes

Every automation is in one of three states, shown as the Status pill on the Automations list:

• Draft—never published. Save as often as you like; a draft runs as a rehearsal (a dry run, below), so nothing it does reaches a real system. Turn it on to let its triggers fire while you test it.
• Published—the live version. Its definition is locked in the editor: you can turn it on or off, run it by hand (the trigger's menu still offers Run as Dry Run for a one-off rehearsal), and open any step to read its settings (a webhook's URL and signing secret included), but not change it. Click Edit to open its revision.
• Revision—a working copy of a published automation, edited and saved on its own. It starts as a full copy of the live definition—graph, variables, secrets, test targets, and settings—so it rehearses with the same inputs. It has its own on/off switch and its own webhook addresses, and it runs as a rehearsal until you publish it. Secrets are shared rather than copied: changing a secret's value in the revision changes it for the live automation at once. A published automation has at most one revision at a time; the list shows it as a row nested under the live one. The two share one run history: the revision's Last Run pane, Activity card, and Runs count read live's runs as well as its own, and a path picker in the revision draws on the payloads live has already produced. A revision's address is its live automation's, with the revision named beside it, so one automation has one link however you reach it.

If the live automation has changed since a revision was created—a restored version is the one way it can—the revision's publish confirmation says so, with both version numbers, before you confirm. Publishing or discarding a revision that still has runs in progress is refused with a message; stop those runs from the run list, or let them finish, and try again.

To publish a draft or a revision:

1. Click Save, so the canvas holds nothing unsaved. Publish stays disabled until it does.
2. Click Publish.
3. Read the confirmation, and click Publish again.

Publishing a draft makes it the live version. Publishing a revision replaces the live definition wholesale and removes the revision; the live automation keeps its own on/off setting, its identity, and the webhook addresses external systems already point at, so nothing outside needs re-registering. A trigger added in the revision was registered when it was added and stays registered.

To abandon a revision, click > Discard revision in its editor. Its runs stay in the run history, badged Revision.

warning

Publishing an automation that is turned on means its next trigger runs for real. The confirmation says whether that is the case.

Dry runs

A draft or a revision always runs as a dry run: the whole flow runs, but no real change escapes. Every step still executes, so branching, looping, and the data passing between steps behave exactly as they would live; only the mutations are held back. A published automation runs live—steps act on their real targets—apart from a one-off rehearsal you start by hand from an on-demand trigger's Run as Dry Run.

Run history says what produced each run: a Draft or Revision badge, a Dry Run badge for a one-off rehearsal of a live automation, and no badge for a live run. A rehearsal is never mistaken for the real thing.

Test targets

A dry run has two ways of holding a mutation back, and which one a step gets depends on whether you have given its integration somewhere safe to go.

Open the automation's settings and use the Testing tab to add Test Targets—one entry per integration, such as a test email recipient or a test Slack channel. During a dry run, every step of that integration sends to the test target instead of its configured destination: a real, observable effect, landing somewhere harmless. A step whose integration has no matching entry makes no external change at all and writes what it would have done to the run log instead.

Some steps let you narrow this further: an email, Slack, or Microsoft Teams step can carry its own test destination that takes precedence over the automation-level target for that step alone.

Use a dry run on its own to rehearse a flow log-only, and add test targets when you want to exercise it against sandbox destinations before going live.

Outbound HTTP during a dry run

Outbound HTTP is the one deliberate exception. By default, a dry run still sends the methods HTTP defines as read-only—GET, HEAD, and OPTIONS—for real, because downstream steps rehearse far more accurately against live response data. Mutating requests—POST, PUT, PATCH, and DELETE—are logged and skipped.

An endpoint is free to break that read-only convention, so you control which methods are sent:

• Everywhere—set Dry Run: Outbound HTTP on the Settings page. Choose None to send nothing during a dry run, Safe Methods Only (the default), or All Methods.
• Per step—the HTTP Request and OpenAPI steps carry the same field on their Advanced tab. It overrides that setting for that step alone.

Neither behavior is left for you to infer. The note beside the step's method states whether that request is sent for real and which policy decided it, and the run log records the same decision every time the step runs in a dry run.

Running, duplicating, and archiving

When the trigger supports manual runs, a run button appears in the toolbar—for the on-demand trigger it reads Run Automation. Click it to start a run and watch the flow execute live. The side panel's Activity section also tracks recent runs live as they happen. See Monitoring and history.

Run always acts on the saved automation, never on edits still on the canvas. If the flow has unsaved changes, Run is grayed out with a tooltip explaining why, and a chip points at Save as the way to unblock it. Repositioning a sticky note doesn't count as a change that blocks Run, since a note can't affect what runs. On a published automation the canvas is locked, but Run stays available on its trigger.

If the on-demand trigger defines a payload, clicking Run Automation opens a form for it first. A Content Type payload opens the normal CMS form for that type. A Custom Shape payload opens the same fields you declared on the trigger—text, number, checkbox, or a repeatable list—as long as every property is one of those; a shape with a nested object or a list of anything but text falls back to a JSON editor instead, since there's no single-field input for it. Submitting the form starts the run with the values you entered.

The toolbar's more-options menu provides:

• Duplicate—create a copy of the automation: the graph, variables, secrets (with their values, as secrets of its own), test targets, and settings. The copy is a new draft, turned off.
• Archive—move the automation to the archive. An archived automation opens read-only, with a banner stating that it can't run and pointing to Restore in this same menu. Archiving a published automation archives its revision with it, and restoring brings both back. Archived automations can be restored or permanently deleted.
• Export—download the automation's definition as a portable JSON file, stripped of anything specific to this workspace. Secret values are never included, only their names.
• Save as Template—add the automation to the template catalog as a template of your own, choosing its kind and tags. Grayed out while the canvas has unsaved changes. See Saving an automation as a template.

A revision's menu offers Discard revision in place of these—a revision is not duplicated, exported, saved as a template, or archived on its own.

Importing an automation

Click Import on the Automations page to bring in a definition exported from this or another workspace—upload the file or paste its JSON. An exported file can hold a single automation or several exported together; either way, import brings each one in as a new draft, turned off, and opens a summary with one card per automation, naming what needs attention before it's ready to run: secrets to re-enter (only their names carry over) and any connections or references that don't resolve in this workspace, left empty for you to reconnect. If several automations that call one another are imported together, the references between their copies still resolve. From a card, Open Automation takes you into the editor to finish configuring it.

Exporting automations in bulk

Select one or more rows on the Automations page and click Export to download all of them as a single file. Automations exported together are rewired to reference each other's imported copies rather than the originals they came from, so importing that same file—into this workspace or another—brings the whole set back in with the connections between them intact.

Version history

Every save is kept as a version of the automation's definition, classified by what changed—Created, Layout only (nodes moved but nothing else edited), or Edited—so a rearrangement doesn't read the same as a real change. Open the automation's History tab for the timeline: the current version pinned at the top, then past versions and status changes (turning the automation on or off) listed newest first. The saves leading up to a publish collapse into the version it publishes, so a published automation's history reads as one version per publish. A revision keeps its own history while it exists.

Opening a past version loads it into the editor read-only. Click Restore this version to make it the current definition, recorded as "Restored from version N" rather than an ordinary edit, so nothing is lost. Restoring changes the definition only: a published automation stays published, so the restored definition is live at once, and a draft or revision stays a rehearsal. The per-node Run control is hidden while viewing a past version, since running always acts on the current definition.

Viewing a past run

Opening a past execution shows the same flow in a read-only view, with each node's status overlaid on its card. See Monitoring and history.