Automations

An automation is a graph: one trigger, then nodes that run in order, with branches, loops and waits. Each published version is immutable, and every firing creates a run you can open and inspect step by step.

The four triggers

Trigger	Fires when
Manual	Someone runs it — from the automation, a button, or ⌘K
Schedule	On a recurring schedule
Event	Something changes in the workspace — a record is created, updated, or deleted
Webhook	An external system POSTs to the automation’s URL. See Automate with webhooks

A run also records why it started: manual, schedule, event, webhook, sub_automation, retry, or failure.

The eleven node types

Node	What it does
Action	Runs one of your actions
Database record	Creates or updates a record directly
Condition	Branches on a test — the if
For each	Loops over a list, running its body per item
Merge	Brings branches back together
Delay	Waits before continuing
Approval	Pauses until a person approves or rejects
Transform	Reshapes values between steps
AI prompt	Runs a prompt and uses the result downstream
Connector operation	Calls a connected app. See Integrations
Sub-automation	Runs another automation as a step

How values move between steps

Every node input is an expression, which is one of:

• Literal — a fixed value
• Path — read from the trigger, another node’s output, or the loop scope. This is how step 3 uses what step 1 produced
• Template — a string with values interpolated into it
• Operation — computed: coalesce, concat, add, subtract, multiply, divide, lowercase, uppercase, length

So “email the owner of the record that just changed” is a path into the trigger, and “Hi {{name}}, your order shipped” is a template.

Building one that’s worth trusting

1. Start from the trigger you actually mean. “When a record’s Status becomes Done” is an event trigger with a condition, not a schedule that polls.

2. Put the condition early. Filter out the runs that shouldn’t do anything before any step with a side effect. A run that does nothing is free; a run that half-did something is not.

3. Use Approval for anything irreversible. Sending to customers, deleting, spending money. The run parks and waits for a person.

4. Read a run before you trust it. Open the run, look at each node’s input and output. Automations fail on the values, not on the shape.

5. Prefer one Action node over a hand-built HTTP call when the action already exists — it’s reusable and its runs are recorded separately.

6. Reach for Sub-automation when a sequence shows up in three automations. Same reason you’d extract a function.

Watching them

Every automation has a run history: status, source, and per-node input, output, error, and attempt count. Failed runs can be retried, and a retry is recorded as its own run with source retry.

Next: Actions, Integrations, Automate with webhooks.