Automation

What it is#

An automation rule answers an event — a task moved to In Review, a deadline coming up — and then does the work: change a status, notify someone, wait two working days and check again. Rules fire against real data as soon as they are enabled.

How to get there#

Work → Automation in the admin console rail, at /<workspace>/admin/automation.

Seeing the list, the rule shapes and the run history needs automation.view. Creating, editing, enabling, deleting, installing a template and running a rehearsal need automation.manage. Without it the toggles are disabled and the New rule and Templates buttons are absent. There is no plan gate.

How to use it#

Read the list#

1. Four counters at the top — Rules, Enabled, Total runs, and Stopped when it is above zero. That last tile only appears when it means something.
2. Each card reads as a sentence: the trigger chip, an arrow, and one chip per action, each with its configured parameters resolved into words rather than ids.
3. Tags say what the rule covers — the project it is bound to or **All projects, and Limited to n** when a project or client scope narrows it further.
4. The footer says how many times it has run and when it last did, the shape of its graph, and its hourly ceiling if one is set.
5. A rule the engine switched off itself carries a red panel saying why, and telling you to fix the cause before starting it again. A rule an admin switched off by hand has no such panel — that is how the two are told apart.

Install a template#

1. Press Templates. Fifteen rules teams write first, grouped as Delivery, Quality, Client, Team and Finance.
2. Search, and pick which project it applies to, or Every project.
3. Press Install. Everything installs switched off. Nothing is sent to anybody until you enable the rule yourself.

Build a rule#

1. Press New rule, or the pencil on an existing one.
2. WHEN — one trigger. The choices are: a task is created, a task moves to a status, a task is assigned, a task's priority changes, a task is due soon (in a given number of days), a task becomes overdue, a comment is added, or a project is created.
3. ONLY IF — an optional gate on the whole rule, off by default. Conditions are field operator value over the facts about the thing that just happened — task status, priority, assignee, title, labels, due date, estimates, project and client, plus who caused the event and what the value changed to. Your own custom fields can be named too.
4. THEN — the ordered steps. Actions are: set status, set priority, assign to, add a label, add a watcher, notify a person, notify the assignee, post a comment, send to a connected tool, or call an external tool on a registered MCP server. A step can also be a wait, in minutes, hours, days or working days, and a branch on its own conditions with a then and an else arm.
5. ADVANCED — the project and client scope, and the hourly ceiling.
6. The pickers only ever offer triggers, fields, operators and actions the server will accept, and the limits shown are the server's own.

See what a rule actually did#

1. Press the clock icon on a card.
2. History lists every firing with its full trace, skipped runs included and listed by default. "Task priority is High — saw Medium — did not match" ends the question; a log of successes cannot answer it.
3. Test points the rule at a task you name and reads back what it would do. It walks the real executor rather than a parallel estimator, so a delay is walked through rather than parked and the trace still records the wait.

What it affects#

• Rules fire on real mutations. Creating a task, updating one, commenting and creating a project all run the engine. Actions taken through the MCP tool surface fire the same rules a human does, so a task created by an outside agent is not a special case.
• The two clock-driven triggers are swept every few minutes rather than hanging off a request. Each firing is claimed against the rule, the task and the task's own due date, so a deadline never notifies twice however often the sweep runs — and rescheduling a task deliberately re-arms it.
• A wait survives a deploy. A parked run is a row holding the step to resume at, the moment to resume and the event to resume with, and a resumed run is the same run with a gap in the middle rather than a second row in the history. A rule edited while a run is parked does not change that run — it snapshots its graph at the start.
• Events reach agents through the same call. An event trigger on an agent fires from the same place a rule does, so a status change cannot fire one and not the other.
• Notify actions ring the bell and the phone. A comment posted by a rule is an ordinary comment on the task.

On mobile#

Admin → Automation reads and stops. Rules that switched themselves off sort to the top, with the reason on the card, and the switch turns one off from wherever you are. Tapping a rule shows its flow drawn read-only and its run history, skipped runs included. Building a rule is web only — a condition grammar and a branching flow are not a small screen's job.

Limits and gotchas#

• The circuit breaker. A rule that runs more than its hourly ceiling — 200 an hour by default — is switched off with a reason and its owner is notified. So is a rule that triggers itself more than three levels deep. There is a second guard on the other axis: when any one item has been touched by automations more than 50 times in an hour, the next rule to reach it is switched off too.
• A rule may hold at most 25 steps, 20 conditions, and a delay of at most 90 days. A delay longer than that is a scheduled task, not an automation.
• A hand-written flat rule is capped at 10 actions; a graph may hold all 25.
• Condition groups nest one level only.
• changed, changed from and changed to only work on fields that keep a before-image — status, priority and assignee. The editor refuses to save one anywhere else, rather than letting a rule quietly never match.
• An MCP tool or a connected integration named in a rule is checked again at firing time. A connection revoked after the rule was written is a refusal then, not at save time.
• Deleting a rule deletes its run history with it, and cannot be undone.

Related#

• Workflow — the stages a rule moves work between.
• Agents — the other unattended actors, and the same event vocabulary.
• MCP servers — where the external tools come from.
• Automation — the engine's model, in one place.
• Notifications — what a notify action produces.