# Automations basics _Triggers, actions, the graph builder, and runs._ Canonical: https://snoze.dev/help/automations-basics/ Automations let your workspace do repetitive work itself — react to something happening, run a sequence of steps, and record exactly what it did. They live in the **Automations** surface and, like everything else in Snoze, they act through the same permissioned kernels people and the API use, so an automation can never do something its creator couldn't. ## Triggers: what starts a run Every automation begins with one trigger: - **Manual** — runs when a person, a button, or the API explicitly starts it. - **Schedule** — runs repeatedly on an interval. - **Event** — runs when a matching workspace event is appended, like a record being created or a field changing, with optional filters on the subject. - **Webhook** — runs when its private HTTP endpoint receives a request. ## The graph: what happens next An automation is a graph of steps. A simple one reads as a linear WHEN/THEN flow; a more involved one branches. The steps you can add include: - **Action** — the unit of real work: create a record, update fields, send a notification. - **Condition** — split down a true or false path. - **Transform** — shape values for a later step. - **Delay** — durably pause until a later time, then continue. - **For-each** — run a branch once per item in a list. - **Approval** — wait for an authorized person to approve or reject before continuing. - **Sub-automation** — call another automation and wait for it. Values pass between steps through a typed expression system, not arbitrary code, which keeps every graph inspectable and safe to replay. ## Draft, publish, run You edit an automation as a **draft** and **publish** when it's ready. Publishing validates the whole graph and freezes it as a version; every new run pins the version it started on, so editing or republishing never disturbs a run already in progress. Background runs execute as the member who created the automation, with that member's current permissions checked at every step. ## Runs are the receipts Every execution is recorded as a **run** with a node-by-node timeline — its inputs, outputs, timing, and status (queued, running, waiting, completed, failed, or cancelled). When something looks off you open the run and see exactly where it went, and you can cancel a run in flight or retry a failed one. > [!TIP] > Good first automations are boring on purpose: notify a channel when a > high-priority record appears, create a weekly review page on a schedule, or > route form submissions with a condition. Start linear, add branches only when > a real case needs one. ## The runs page Open **Automations** in the sidebar and switch the toggle from **Automations** to **Runs**. It lists every run across the workspace, newest first. Filter by status, search by automation name, and open a failed run to read the error inline. Retrying a run starts a fresh one from the same trigger data; the retry is recorded as its own run so the history stays honest. ## Actions, buttons, and AI An **action** is a reusable step you can also trigger by hand — bind one to a **button** in a page or dashboard and a click runs the whole routine. The AI assistant can run those same actions conversationally, pausing for your approval before anything high-stakes. ## Go deeper - [Buttons and actions](https://snoze.dev/help/buttons-and-actions/) — package work into an action and run it with a click. - [Work with the assistant](https://snoze.dev/help/work-with-the-assistant/) — run actions in plain language. - [Approvals and safety](https://snoze.dev/help/approvals-and-safety/) — how high-stakes steps pause for a human.