The Rule That Fires Twice
An ops team built automation on a 'Client Requests' project. Rule A: when a task is added to the 'New' section, set Due date to today + 3 days and assign to the on-call rota member. Rule B: when Due date is changed, post a comment tagging the assignee. A third rule, Rule C, moves any task with the 'Urgent' checkbox checked to the 'Escalation' section and sets Priority to High. Last week a task was created via a form with Urgent already checked. The team observed: the due date was set, a comment appeared tagging the assignee, the task moved to Escalation, and Priority was set to High - but the assignee reported getting two notifications, and the due date comment appeared before the task had an assignee in one case. They also noticed Rule C moved a task to Escalation that a human had just deliberately moved back to New.
1. Explain the ordering and double-notification symptoms in terms of how rule triggers chain, and identify the design flaw.
Read the worked answer
The symptoms are consistent with automation chaining: Rule A's actions (set Due date, set assignee) are themselves changes that satisfy other rules' triggers.
Sequence for the form-created task:
- Task added to New → Rule A fires. It sets Due date and assignee.
- Setting the Due date satisfies Rule B's trigger ('Due date changed') → Rule B fires and comments/tags the assignee.
- Setting the assignee is another change; if any rule or notification watches assignment, that's the second notification.
- Rule C fires because Urgent is checked → moves to Escalation, sets Priority High.
The 'comment appeared before the assignee existed' detail points to action ordering within a single rule or across near-simultaneous rules: the comment action ran against a task whose assignee field hadn't been committed yet, so the tag resolved empty or to a stale value. Rules don't guarantee the human-intuitive order of their own actions when multiple rules touch the same task in the same beat.
The flaw: the team built rules that trigger on side effects of other rules, without guarding against re-entry. Rule B watches a field that Rule A writes; nothing prevents the cascade.
2. Propose concrete changes to stop the double notification and the empty tag, without losing the 'comment when due date changes' behavior.
Read the worked answer
Guard the chain rather than delete the useful rule:
- Make Rule B ignore automated writes. Most engines let a condition scope the trigger (e.g., 'Due date changed' AND 'changed by a person', or exclude changes made by this rule). If the platform can't express 'changed by a human', narrow Rule B to fire only when the due date moves after the task has an assignee - a condition on assignee is not empty.
- Reorder Rule A's actions so assignment happens before any action that other rules watch. If the engine won't guarantee order, split Rule A into two rules with an explicit dependency, or have Rule A set the assignee and let a separate rule set the due date once an assignee exists.
- Add a re-entry guard to Rule C. A simple, effective pattern: Rule C should only fire when the task is not already in Escalation and the move wasn't human-initiated. The cleanest fix is a condition 'Section is not Escalation' plus a 'moved by automation' scoping, so a human moving a task back to New isn't immediately overridden.
- Consolidate. Three rules that all touch the same task on creation are a chain waiting to misfire. Folding A and C into one rule with ordered actions (assign → set due date → check urgent → route) removes the inter-rule race entirely.
3. The human who moved a task back to New was overridden by Rule C. What governance practice prevents this class of conflict?
Read the worked answer
This is an automation-vs-human authority conflict, and the fix is a policy, not a tweak.
- Decide who wins, per field/section. For routing, either automation owns the section (humans request changes via a field) or humans own it (automation only routes on creation, never re-routes). Pick one and encode it.
- Scope rules to transitions, not states. 'When Urgent is checked' re-fires whenever the condition holds; 'when Urgent becomes checked' fires once. Transition-scoped triggers don't fight a human who has since changed the state.
- Leave an audit trail and a visible actor. The task history should show the automation moved it back. If a human sees their move silently reversed, trust in the system collapses - and that's how teams end up disabling rules wholesale.
- Review rule inventory on a cadence. A short list of rules, each with an owner and a stated intent, makes conflicts like this obvious before they bite. Three rules with overlapping reach on the same task is the smell.