--- title: "Automation" slug: admin/automation url: https://projectri.com/docs/admin/automation section: admin audience: admin app_route: "/[slug]/admin/automation" permissions: [automation.view, automation.manage] mobile: "/admin/automation" updated: 2026-09-08 source: Projectri documentation --- # Automation Rules that react to what happens in this workspace — a trigger, optional conditions, and an ordered flow of actions, waits and branches. ![Automation](https://projectri.com/docs-shots/admin-automation.png) ## 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 `//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 > [!WARNING] > The graph is the rule. The flat action list beside it is derived from the > graph on the server, not taken from what a client sends. A rule that could > disagree with itself would display one thing and run another, which is exactly > what happened before the derivation existed. - **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](/docs/admin/workflow) — the stages a rule moves work between. - [Agents](/docs/admin/agents) — the other unattended actors, and the same event vocabulary. - [MCP servers](/docs/admin/integrations-mcp) — where the external tools come from. - [Automation](/docs/features/automation) — the engine's model, in one place. - [Notifications](/docs/features/notifications) — what a notify action produces. ## Related - [Workflow](https://projectri.com/docs/admin/workflow.md): The stages work moves through, the levels of the work-item hierarchy, the approval chains that sign work off, and the sales pipeline stages. - [Agents](https://projectri.com/docs/admin/agents.md): The directory of unattended actors in this workspace — what each one may do, who is accountable for it, and the button that stops it. - [MCP servers](https://projectri.com/docs/admin/integrations-mcp.md): Register outside MCP servers so this workspace's automations can call their tools, choose which tools are callable, and read what was sent. - [Automation](https://projectri.com/docs/features/automation.md): Rules that watch for something happening and then act — the triggers, the conditions, the actions, and the guards that stop a rule running away. - [Notifications](https://projectri.com/docs/features/notifications.md): What Projectri tells you about, on which of the five channels, what you can turn off, and the difference between a channel and a subscription.