Automations
Automations are "when this happens, do that" rules: when content is published → rebuild the website, every night → send a digest email. They connect the CMS to the outside world — cache purges, site rebuilds, notifications, syncs — without anyone polling an API.
Integrating with webhooks? Payload shapes,
templates, secrets, and delivery semantics are covered in Automations & webhooks (concepts).
Automations are built from two pieces, managed separately so delivery settings aren't duplicated:
Actions (Settings → Actions)
An action is a reusable delivery step with its own credentials:
| Type | What it does |
|---|---|
| Webhook | HTTP request to a URL, with configurable headers and parameters |
| Email delivery to a recipient list | |
| Void | Internal no-op — useful for testing trigger logic |
Actions store protected secrets (API keys, signing secrets) attached to the action itself; existing secret values stay hidden and multiple automations can reuse the same destination safely. The actions table shows linked automations, execution status, and last execution; an action with linked automations can't be deleted until they're detached.
Automations (the triggers)
An automation picks a trigger, links an action, and sets guardrails:
Trigger types
| Trigger | Fires |
|---|---|
| Content published | When an entry transitions to published; context includes the full record, previous state, and timestamps |
| Content unpublished | When a published entry is taken offline |
| On insert / update / delete | On row-level changes of a chosen resource type; on update can watch specific columns |
| Time based | On a cron expression |
| Manual | Only when run by hand |
Triggers can carry conditions (only fire when the record matches rules) and payload values — including placeholders resolved from the trigger context (e.g. the entry's slug or cache tags for targeted CDN invalidation).
Guardrails
Automations can be activated/deactivated and can carry execution limits (n of m used, remaining counter) to keep runaway triggers from hammering a target.
Execution history
The Execution History view lists every run across all automations — queued, running, completed, failed — with source (trigger, schedule, manual, replay), timing, duration, the stored context (trigger payload) and result, and error details for failures. Replay re-runs a past execution with its original context — the fastest way to retry a broken workflow after fixing the target.