Skip to main content
An automation starts a run without anyone typing. “Every weekday at 9, review yesterday’s failed CI runs.” “When an issue is opened in acme/shopfront, triage it.” “When the nightly workflow fails, open a follow-up.” The run is an ordinary chat you can open afterwards, with the full transcript, so you can see exactly what the agent did.
The Automations list showing a schedule, a webhook and a GitHub automation

Workflows → Automations. Example data.

​
Declare, then activate

Automations have two halves, and keeping them apart is what makes a workflow shareable. A workflow declares when it should run in a triggers: block of its YAML. The declaration says the source (a schedule, a webhook, an integration event, another workflow’s outcome), an optional filter, and how the event’s data becomes the workflow’s inputs. Declaring a trigger fires nothing. You then activate it, which says as whom and where: your account, a project, the machine whose tools the run uses (or no machine), and, for an integration event, which connected account it listens through. In the app, a workflow’s detail page lists its declared triggers with an Activate button. The activation re-reads the declaration every time it fires, so editing the workflow’s triggers: block changes the automation. If you rename or remove the declaration, the activation is marked broken and fires nothing until you restore it.
Each entry has a unique name and exactly one source. The fields around the source are the same for every kind: Inside templates and filters, trigger.payload is the event’s data and trigger.kind says what fired. Unknown keys in a triggers: block are errors, not ignored: a mistyped filtr: would otherwise mean a trigger that fires on everything.

​
The four kinds

​
Unattended by design

Nobody is watching an automation’s run. The agent is told to decide and proceed rather than ask, questions and approvals resolve immediately with no answer instead of waiting, and a run that hits trouble records it rather than parking forever. Design workflows for this: give them everything they need in the prompt and inputs, and assume nothing can be clarified mid-run. A workflow that should only ever start from its triggers, never from a chat, can set automation_only: true.

​
Watching your automations

Workflows → Automations lists every automation across your projects, with a “coming up” timeline of the next 24 hours of scheduled runs and each automation’s health, computed from its last ten firings: A run that launched and then failed counts as a failure, not just a launch that errored. Opening an automation shows its history: each firing, what it did (launched, skipped, failed) and a link to the run it started.
Run history for a scheduled automation

An automation's run history. Example data.

​
From the command line

reliant trigger manages schedule automations: create, list, get, update, enable, disable, fire, events and delete. Webhook, integration and workflow-event automations are activated from the app (or by an agent with the activate_trigger tool). See Schedules for the commands.