Working with others
When two rules collide
Automations that contradict each other, loop, or stop making sense together.
Automations get added one at a time and always look reasonable on their own. The problem appears in month six, when there are fifteen and nobody holds in their head how they interact.
The four symptoms
| Symptom | What is usually behind it |
|---|---|
| Someone gets three alerts about the same thing | Two rules cover the same case |
| An alert arrives and a minute later the opposite one | One rule undoes what the other does |
| Consumption rises with no new activity | Something fires far more than expected |
| People have stopped reading alerts | The worst of the four, and the quietest |
Important
The fourth symptom is the one to watch. When automatic alerts are ignored as a matter of habit, you do not have a rules problem: you have an alerting system that no longer alerts, and the day an important one arrives it will be ignored too.
How to untangle it
- 1
List the active rules and what triggers each
Two doing almost the same thing nearly always turn up.
- 2
Check how many times each has fired
The number separates the useful ones from pure noise.
- 3
Switch off before tuning
If a rule has added nothing in three months, remove it. Tuning it prolongs the problem.
- 4
And keep one rule per situation
Two rules for the same case always end up disagreeing.
Watch out
Beware rules that trigger on another rule's result. That is where loops come from: the first marks something, the second reacts to the mark, and that re-triggers the first. If two rules watch each other, one of them should be manual.
How to avoid getting there
That second line helps most at review time: a rule whose purpose nobody can explain is exactly the one to remove.
Worth knowing
Every firing consumes like a manual action. A looping rule does not only create noise: it creates spend, and it is usually discovered through the invoice before the complaints.
›Can they be switched off temporarily?
Yes, and that is sensible while diagnosing.
›How do I know which rule did what?
The activity log shows it, including the responsible rule.
›How many rules are too many?
When you can no longer explain from memory what each does.
A real case
The situation
A team stops reading alerts because they arrive duplicated and contradictory.
What you do
- Lists active rules and switches off those that added nothing in three months
- Keeps one rule per situation
What you get
Alerts get read again because they mean something again.
The situation
Two rules fire on the same event and the supplier gets two different notices the same day.
What you do
- Checks which rules are active on that event
- Decides which one prevails and disables or narrows the other
- Verifies with a real case before treating it as solved
What you get
The supplier receives a coherent message and the system stops contradicting itself.
The situation
One rule closes the file and another reopens it.
What you do
- Orders the conditions so they do not overlap
What you get
The file has one status, not two.
The situation
Nobody knows which rule won in a specific case.
What you do
- Checks the run history
What you get
The behaviour is explicable.
The situation
A rule is added without looking at the existing ones.
What you do
- Reviews the existing ones before creating a new one
What you get
The system does not accumulate contradictions.
The situation
Two departments create rules for the same process.
What you do
- Centralises who can create rules
What you get
Rules answer to shared criteria.
The situation
One is disabled and something needed stops happening.
What you do
- Notes what it did before disabling it
What you get
The gap is visible rather than discovered.
The situation
The overlap only surfaces when a supplier complains.
What you do
- Reviews the rule set periodically
What you get
The conflict is caught before it reaches outside.
This article answers
- two automations contradict each other
- rule firing in a loop
- too many automatic alerts
- reviewing our active rules