Ceyu

Automation rules

A rule watches for something happening and then does something. That is the whole model, and keeping it that small is what makes the results predictable.

Availability

Automation rules and recurring tasks are included from the Studio plan.

The shape of a rule

Every rule has three parts:

  1. Trigger — what happened. A status change, an assignment, a date passing, a task being created.
  2. Condition — optional narrowing. Only in this project, only above this priority, only when a field has a given value.
  3. Effect — what to do. Set a field, assign someone, move status, create a follow-up task, notify a person.

Simulate before you switch it on

A rule can be run against your existing data as a simulation. It reports what it would have done, without doing any of it.

This matters more than it sounds. The classic automation failure is a rule that looks right, gets enabled on a Friday, and quietly reassigns four hundred tasks over the weekend. Simulating first turns that into a list you can read.

Run history

Every execution is recorded: what triggered it, what it changed and whether each effect succeeded. When somebody asks why a task moved, the answer is in the run history rather than in a guess.

Recurring tasks

Separate from rules, and simpler: work that comes back on a schedule creates itself. Monthly reporting, weekly backups, the quarterly licence review.

Pair a recurring task with a task template and the checklist arrives already filled in.

Where to stop

Automation is worth it for work that is genuinely mechanical and happens often. It is a poor substitute for a decision.