Automations
"When this happens, do that" — deterministic rules, with a log of every time one fired.
An automation is a rule: one trigger, up to eight conditions, up to five actions. Move a task to Done and comment on it; assign new work with no owner to the team lead; nudge the owner the day before a deadline.
An automation never asks a model anything. It has no judgement — it does exactly what you wrote, every time, and when it doesn't fire it tells you which condition stopped it. That predictability is the point, and it's why Automations is a separate thing from Autopilot, Hoot and Nooties. See Which AI does what.
Where rules live
| Scope | Where | Applies to |
|---|---|---|
| This project | The Noot's Automations tab | Only that project. Add the tab from the + on the tab strip. |
| Workspace-wide | /app/automations | Every project. A project's effective rules are its own plus the workspace's. |
The workspace console also lists every project rule on a Noot you can see, so there is one place to answer "what is running in here?"
The nine triggers
| Trigger | Fires when |
|---|---|
| A task is created | Any new task — by a person, an import, a meeting or another rule. |
| A task changes status | It moves between board columns. |
| A task is completed | It reaches Done. |
| A task is assigned | Somebody is put on it. |
| A label is added to a task | A label lands. |
| A due date is approaching | Checked by the server every 15 minutes. |
| A task becomes overdue | Also checked every 15 minutes. |
| A Noot is created | Workspace-wide rules only — a project rule can't watch for its own creation. |
| Another tool calls this rule's URL | An inbound webhook. See below. |
"Due soon" and "overdue" are states, not events, so a sweep every quarter of an hour would otherwise fire them forever. Each one fires once per task and only re-arms if the due date genuinely changes — re-saving a task doesn't restart the nagging.
The eleven actions
- On the task — move it to a column, assign it, set its priority, add a label, set a due date, comment on it, or create a follow-up task.
- Tell somebody — an in-app notification or an email, to the assignee, the Noot's leader, the relevant team leads, or a named person.
- Elsewhere — post in a chat channel, or send to your outgoing webhooks.
Message text takes tokens — {task}, {noot}, {assignee}, {status}, {due}, {rule} — and on a webhook-triggered rule, any field of the payload that arrived, as {payload.field}.
Conditions
Conditions narrow a trigger: project, status, priority, label, assignee, title, due date, whether it's overdue, and (on a webhook rule) the incoming payload. They are all ANDed — every one has to hold.
Start from a recipe
Thirteen ready-made rules in five groups — Triage, Ownership, Deadlines, Reviews and Comms — including "Reviews go to the team leads", "A deadline with nobody on it", "'Blocked' reaches a human" and "Anything shipped gets verified". A recipe that needs something your workspace has to supply (a team, a person, a channel) opens the builder pre-filled rather than saving a rule that could only ever log "skipped".
The run log
Every firing writes a row, including the ones that matched the trigger and were then filtered out — a silent rule is indistinguishable from a broken one, so nothing here is silent.
| Outcome | Means |
|---|---|
| Ran | The trigger matched, the conditions held, the actions ran. |
| Skipped by a condition | It arrived and one of your conditions ruled it out. The log names which. This is the rule working as written. |
| Failed | An action itself went wrong, with the error. |
An action that fires another rule goes exactly one hop deep, and a rule that has already run in the same chain of changes will not run again in it. Both limits are written into the log when they bite, so a rule that looks like it didn't run can always be explained.
Being called from another tool
Pick Another tool calls this rule's URL and saving the rule mints its inbound address for you — there is no separate "generate" step, because a webhook rule with no URL is a rule that can never fire. The URL's secret is the credential: anyone holding it can fire that one rule and nothing else. Rotate it to invalidate the old one immediately, or Revoke it to leave the rule in place and unreachable.
The card shows calls received rather than only runs, deliberately: "0 runs" can't tell you whether nothing ever arrived or everything that arrived was filtered out. Full request and response details are in The inbound automation hook.
Who can write one
- A project rule: whoever may shape that project's tab strip — its creator, its leader, a team lead on it, a project manager, or an org admin.
- A workspace rule: someone who can edit the organization.
- Anyone who can read the project can see its rules and its run log. Only the people above see the write controls or the hook URL.
Automations are on the Team plan and above. There is a monthly ceiling on how many actions a workspace runs — 1,000 on Team, 10,000 on Business, unlimited on Enterprise. Reaching it writes one log line saying so, and rules resume at the start of the next month or immediately on a higher plan. Runs skipped by a condition don't count against it.