Automation

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#

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#

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#

• **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 — the screen, and the prebuilt templates.
• Notifications — where a rule's notice lands.
• Integrations — the tools "Send to a connected tool" can reach.
• My Tasks — where most of what a rule changes shows up.