---
title: "Automation"
slug: features/automation
url: https://projectri.com/docs/features/automation
section: features
audience: admin
permissions: [automation.view, automation.manage]
mobile: false
updated: 2026-09-08
source: Projectri documentation
---

# Automation

Rules that watch for something happening and then act — the triggers, the conditions, the actions, and the guards that stop a rule running away.

![Automation](https://projectri.com/docs-shots/admin-automation.png)

## What it is

An automation rule watches for one event in the workspace, checks whatever
conditions you set, and then runs a sequence of steps — actions, waits and
branches. Rules fire from every path equally: a change made by hand, by the API,
by Nia or by another rule is the same event.

Every firing is recorded, including the ones that did nothing, because "why did
this task move?" has to be answerable.

## How to get there

**Admin → Automation**. Reading the rules and their history needs
`automation.view`, which members hold by default; creating, editing and
enabling one needs `automation.manage`. There is no plan gate.

## How to use it

### Build a rule

1. **Admin → Automation → New rule**.
2. Pick the trigger. Some carry a parameter — the status to watch for, the
   priority, how many days before a due date.
3. Optionally add a **gate**: conditions evaluated once, before any step runs.
4. Add steps. A step is an action, a delay, or a branch.
5. Scope it. A rule with no project scope fires across the whole workspace,
   which is rarely what was meant.

### The triggers

| Trigger | Fires |
|---|---|
| `task.created` | once, when a new task appears |
| `task.status_changed` | when a task enters the chosen status |
| `task.assigned` | when a task gains an assignee |
| `task.priority_changed` | when a task is set to the chosen priority |
| `task.due_soon` | once, when a task's due date is within the given number of days |
| `task.overdue` | once, when a task passes its due date without reaching Completed |
| `comment.added` | when a comment is posted |
| `project.created` | when a project is created |

The two clock-driven triggers are not hung off a request — they are swept every
few minutes, and each firing is claimed against the rule, the task and the *due
date*. So a deadline never notifies twice however often the sweep runs, and
rescheduling a task correctly re-arms it.

### The actions

| Action | Does |
|---|---|
| Set status | moves the task |
| Set priority | sets it |
| Assign to | assigns the task to a chosen person |
| Add label | attaches a label by name |
| Add watcher | subscribes somebody to the thread |
| Notify a person | a notification to a named person, with an optional note |
| Notify the assignee | the same, addressed to whoever holds it |
| Post a comment | writes a comment on the task |
| Send to a connected tool | posts into Slack, Teams, Discord, Jira, Linear, Notion, GitHub, GitLab, Zapier, Segment, Amplitude, a mailbox or a calendar |
| Call an external tool | invokes a tool on an MCP server your workspace has registered |

### Add a condition

1. Conditions test one field with one operator against one value. Both lists are
   fixed — there is no expression language.
2. Fields cover the task's status, priority, assignee, title, labels, due date,
   estimate in hours or points and project; the project's name, status and
   client; who caused the event; and what the value changed to. Your own custom
   fields are available as `custom.<key>`, including computed ones.
3. Operators: is, is not, contains, does not contain, is empty, is not empty, is
   greater than, is less than, is between, changed, changed from, changed to.
4. Group them with **all of** or **any of**. Groups nest one level, and no
   further — an evaluator nobody can debug is not worth the flexibility.
5. The three "changed" operators only work on fields that track their previous
   value: status, priority and assignee. Choosing one elsewhere is refused when
   you save, rather than being a rule that silently never matches.

### Add a wait or a branch

1. A **delay** pauses the run for a number of minutes, hours, days or **working
   days** — the last reads your workspace's working week.
2. A **branch** evaluates a condition group and takes one of two paths.
3. A rule may hold at most 25 steps, 20 conditions, and no delay longer than 90
   days. Beyond that it is a scheduled task, not an automation.

### See whether it fired

1. Open the rule's history.
2. Every run is a row with a trace: what each condition saw and what each step
   did, in order. Skipped runs are recorded too, with the condition that skipped
   them — that is usually the answer you came for.
3. A run ends in one of: completed, waiting on a delay, skipped by scope,
   skipped by a condition, skipped by the rate limit, aborted for looping, or
   failed.

### Try one without consequences

A **dry run** walks the graph over an entity you choose and writes nothing. It
is the difference between a nervous admin and a user.

## What it affects

- **Everything a rule does is a real change.** A status a rule sets notifies the
  assignee, writes to the timeline and appears in the audit log, exactly as if
  somebody had dragged the card.
- **Rules do not cascade into each other from their own effects.** A rule fires
  against the event that entered the runner; its own effects are not fed back
  in, so two rules cannot ping-pong. Where a cascade is legitimate it carries a
  depth, capped at three.
- **A broken rule never fails the person who triggered it.** Moving a task to
  Done cannot 500 because an admin wrote a rule naming a deleted user; the rule
  loses its own effect and nothing else.
- **"Send to a connected tool" spends your workspace's credential.** A revoked
  webhook turns the integration card red rather than failing into a log nobody
  reads.

## On mobile

The phone shows automation under **Admin** and can read rules and their run
history. Building one is web-only: a graph editor is a multi-pane authoring
surface rather than a small screen version of itself.

## Limits and gotchas

> [!WARNING]
> **The graph is what runs.** A rule's flat list of actions is a *mirror*
> derived from the graph, kept for the summary line on the rule list. Every
> writer derives it, so the two cannot disagree — but if you ever see a rule
> whose summary and whose steps differ, believe the steps.

- **Three rate caps, and they exist because automation is the easiest way to
  damage a workspace at scale.** 200 runs per rule per hour by default, 50 runs
  against one entity per hour across all rules, and 50 steps in a single run.
- **A rule that cascades too deep disables itself** with a reason you can read.
  Failing silently forever is the worse of the two outcomes.
- **The clock triggers are checked every few minutes, not instantly.** "Due in
  two days" means the next sweep after the boundary.
- **A scope is not optional in practice.** A workspace-wide rule that adds a
  label to every created task is a rule you will spend a week undoing.
- **"Call an external tool" is re-checked at firing time.** An MCP server whose
  connection was revoked after the rule was saved refuses then, not at save.

## Related

- [Automation](/docs/admin/automation) — the screen, and the prebuilt templates.
- [Notifications](/docs/features/notifications) — where a rule's notice lands.
- [Integrations](/docs/features/integrations) — the tools "Send to a connected tool" can reach.
- [My Tasks](/docs/workspace/my-tasks) — where most of what a rule changes shows up.

## Related

- [Automation](https://projectri.com/docs/admin/automation.md): Rules that react to what happens in this workspace — a trigger, optional conditions, and an ordered flow of actions, waits and branches.
- [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.
- [Integrations](https://projectri.com/docs/features/integrations.md): The tools Projectri can connect to, what each connection actually does, how credentials are stored, and what a readiness badge means.
- [My Tasks](https://projectri.com/docs/workspace/my-tasks.md): Every task assigned to you — or the whole workspace — as a Kanban board, a table or a timeline, with counts, a due-date strip, saved views and board setup.