---
id: KB-CL-013
url: https://app.codecontract.io/help/collaboration/when-two-rules-collide
idioma: en
categoria: colaboracion
subcategoria: automatico
audiencia: usuario
nivel: avanzado
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-CL-005, KB-CL-010]
citadoPor: [KB-CL-015, KB-CL-019]
---

# When two rules collide

_Automations that contradict each other, loop, or stop making sense together._

**Responde a:** two automations contradict each other · rule firing in a loop · too many automatic alerts · reviewing our active rules

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.

> [!WARNING]
> 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

**En corto**

- Add one at a time and wait a month before the next.
- Write in one line what problem each solves.
- And review the set twice a year, not when it already hurts.

That second line helps most at review time: a rule whose purpose nobody can explain is exactly the one to remove.

> [!NOTE]
> 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.

## Ejemplos

**A team stops reading alerts because they arrive duplicated and contradictory.**

- Lists active rules and switches off those that added nothing in three months
- Keeps one rule per situation

→ Alerts get read again because they mean something again.

**Two rules fire on the same event and the supplier gets two different notices the same day.**

- 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

→ The supplier receives a coherent message and the system stops contradicting itself.

**One rule closes the file and another reopens it.**

- Orders the conditions so they do not overlap

→ The file has one status, not two.

**Nobody knows which rule won in a specific case.**

- Checks the run history

→ The behaviour is explicable.

**A rule is added without looking at the existing ones.**

- Reviews the existing ones before creating a new one

→ The system does not accumulate contradictions.

**Two departments create rules for the same process.**

- Centralises who can create rules

→ Rules answer to shared criteria.

**One is disabled and something needed stops happening.**

- Notes what it did before disabling it

→ The gap is visible rather than discovered.

**The overlap only surfaces when a supplier complains.**

- Reviews the rule set periodically

→ The conflict is caught before it reaches outside.