Rules and Automation
Trigger, condition, action
Rules automate repetitive work. Every rule has a trigger (something happens, e.g., task added to section, field changed, due date approaching), optional conditions (filters that must be true), and actions (assign, move section, set field, comment, complete). Rules run per project and only on tasks in that project. Understand that a rule fires when the trigger event occurs; it doesn't retroactively apply to existing tasks unless you build it to.
Building reliable automations
Conditions narrow scope so a rule doesn't fire on every task. Actions can chain - a rule can move a task and set a field. Be careful with rules that trigger each other: a rule that moves a task into a section can trigger a second rule watching that section, creating loops or unexpected cascades. Test in a small project first.
Traps in questions
Common traps: assuming rules apply across all projects (they don't - they're project-scoped), or that a rule runs on tasks added before the rule existed (it doesn't). Another is confusing a condition with a trigger: conditions don't cause a rule to run, they gate it. Questions may also test that automations respect permissions - a rule acting on behalf of a user can only do what that user could do.
Worked example
Trigger: task moved to Review. Condition: Priority is High. Action: assign to the review lead and post a comment tagging them. This ensures only high-priority reviews get escalated, avoiding noise on routine items.