--- url: /concepts/automations.md description: >- How a trigger, conditions and actions let Hule do the routine part of your process for you. --- # Automations An **automation** does the next routine step for you: when something happens to a task — or at a time you set — Hule runs a list of actions. Workspace admins build them, and each one covers the whole [workspace](/concepts/hule-model), a folder or a list. > **An automation reads as one sentence: when this happens, here, only if this is true, then do these steps.** The automation editor lays that sentence out in four sections, one per part. ## Automation anatomy: when, where, only if, then ```mermaid flowchart LR W["When: a trigger fires"] WH["Where: whole workspace, a folder or a list"] OI["Only if: the task matches conditions"] TH["Then: actions, in order"] T["Task"] NX["Another automation"] W -- "fires for a task in" --> WH WH -- "passes the task to" --> OI OI -- "lets through to" --> TH TH -- "changes" --> T T -- "can fire" --> NX ``` The actions run one after another, even if one of them fails, and their changes can fire another automation in turn. ::: info What sets off the next automation * Task changes fire task triggers. * **Add comment** fires comment triggers. * **Notify**, **Add watchers** and **Remove watchers** fire nothing. ::: ### When: the trigger is an event A trigger is the moment something happens. There are three groups: | Group | Fires when | Worth knowing | |---|---|---| | **Tasks** | a task is created, updated or deleted | an update trigger can watch chosen fields (**When any of these change**) and even the value a field changes to, for example "priority changes to Urgent" | | **Comments** | a comment is created, updated or deleted | the automation works on the comment's task: **Where** and **Only if** check that task, and the actions change it | | **Time** | **On a schedule** (every N days, weeks, months or years) or **Before or after a date** (for example two days before a task's due date) | times are in the [time zone](/guides/set-up-notifications) of whoever last saved the automation, shown in the editor | An **On a schedule** automation is not tied to a task, so it has no **Where** or **Only if**, and its actions are limited to **Notify** and to **Create task from template**, which you get only from the **Weekly task** and **Monthly task** presets. ### Where: the part of the tree it covers **Apply in** offers: * **Everywhere** — the whole workspace; * **Folder** — every list inside it, nested folders included; * **List** — one list. A folder covers its **Private** branches too, unlike [sharing](/concepts/sharing), which stops at them, so you set a process once for a whole area of work. More about the tree in [Folders inside folders](/concepts/hierarchy). ### Only if: the conditions are a state Conditions use the same filter builder as [views](/concepts/views), with the same task fields ([Filter, sort and group a view](/guides/filter-sort-and-group-a-view)). **When** is an event, the moment a field changes; **Only if** is a state that must hold at that moment (every field and operator: [View filters](/reference/view-filters)). Keep them apart: *when* priority changes to Urgent, *only if* the task is not done yet. An automation without conditions acts on every task its trigger fires for. ::: warning Me (current user) is refused An automation runs for nobody in particular, so a condition on **Me (current user)** can't be saved. Name the person instead. ::: ### Then: the actions Actions run in the order you drag them into. They fall into a few groups: | Group | Actions | |---|---| | Set a field | **Set status**, **Set assignee**, **Set priority**, **Set due date**, **Set start date** | | [Tags](/guides/tag-tasks) and [watchers](/guides/assign-and-watch-tasks) | **Add tags**, **Remove tags**, **Add watchers**, **Remove watchers** | | Move | **Move to list** | | [Subtasks](/guides/break-down-with-subtasks) | **Add subtask**, **Complete all subtasks**, **Delete all subtasks**, **Delete subtasks matching…** | | Talk | **Add comment**, **Notify** ([notifications](/guides/set-up-notifications)) | | New work | **Create task from template**, only in the **Weekly task** and **Monthly task** presets | The actions of the first three groups can act on **The task** or on its **Parent task** (**Apply to**). Every action is in [Automation triggers, conditions and actions](/reference/automation-triggers-and-actions). ::: danger Deleted subtasks don't come back **Delete all subtasks** and **Delete subtasks matching…** remove subtasks for good, with their history. Add a condition so they run only where you mean them to. ::: ## Urgent bugs routed to on-call: an example A team keeps bug reports in a list called **Bugs**. Urgent bugs must reach the on-call developer at once: | Section | Setting | |---|---| | When | **Task updated**, **Priority** changes to Urgent | | Where | **List** — Bugs | | Only if | **[Stage](/concepts/statuses)** is not **Done** | | Then, 1 | **Set assignee** — the on-call developer | | Then, 2 | **Add comment** — the text below | | Then, 3 | **Notify** specific people — the team lead | ```text Escalated to on-call ``` Raising the priority is enough; a bug already in a **Done** status stays quiet. The **Automation Store** has a preset to start from: **Urgent ping**, which notifies the assignee when a task turns Urgent ([Create an automation](/guides/create-an-automation)). The task's **Activity** ([See what changed in a task](/guides/see-task-history)) shows **Automation** as the author of each change. ## Guardrails: chains, loops and failures Because one automation's changes can fire another, Hule limits what a chain can do: * A chain stops once 11 automations have run one after another: the changes made by the eleventh fire nothing more. * An automation that is already running in the chain is skipped, so two automations cannot set each other off forever. * An automation that fails 10 times in a row turns itself off; you turn it back on with **Re-enable** once the cause is fixed. * **Skip during bulk operations** is on for every new automation: it stays quiet when many tasks change at once, such as a [multi-select edit](/guides/edit-tasks-in-bulk) or an [import](/guides/import-from-another-tool). Each time an automation is considered for an event, the **Automation Log** ([Create an automation](/guides/create-an-automation)) records every one of its actions, with the reason: | Status | Means | Kept for | |---|---|---| | **Ran** | the action ran | 30 days | | **Skipped** | a check stopped it | 7 days | | **Failed** | the action ran into an error | 30 days | ## Automation permissions and settings pages Automations belong to the workspace, not to a person: they are its shared process, so the people who manage the workspace own them. They live in **Workspace settings** → **Automations** (click your name at the bottom of the sidebar), where you build them from a preset or from scratch ([Create an automation](/guides/create-an-automation)). Every member can see which automations exist. ::: warning Who can build automations Creating and editing automations, and reading the log, take the automation permissions that the **Admin** and **Super Admin** [permission sets](/reference/permissions-and-access) carry. ::: ## Automations in the Hule model * An automation attaches to the same tree as everything else: workspace, folder or list — see [The Hule model](/concepts/hule-model). * **Set status** moves a task through its list's statuses, and the status's stage decides whether the task counts as done — see [Statuses and status templates](/concepts/statuses). * Conditions use the view filter builder, so a view filter works the same in an automation, apart from **Me (current user)**: see [Views as lenses on tasks](/concepts/views). ## Automation guides and recipes * [Create an automation](/guides/create-an-automation): build your first one step by step. * [Automation triggers, conditions and actions](/reference/automation-triggers-and-actions): every option in one table. * [Automate the routine steps](/recipes/automations-that-do-work): automations that save real work.