---
id: KB-CL-019
url: https://app.codecontract.io/help/collaboration/when-to-switch-an-automation-off
idioma: en
categoria: colaboracion
subcategoria: automatico
audiencia: usuario
nivel: intermedio
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-CL-013, KB-CL-010, KB-CL-015]
citadoPor: [KB-CL-002]
---

# When to switch an automation off

_Plenty is said about which ones to switch on. Spotting which one is doing harm matters as much and nobody says it._

**Responde a:** an automatic rule hurts more than it helps · disabling an automation · the team works around the rule · too many automatic notices

Automations are built with a clear purpose and stay forever, even after the work they described has changed. Nobody reviews them because they do not annoy enough to deserve an afternoon — only enough for people to learn to dodge them.

## The signs that one is surplus

| Sign | What it really means |
| --- | --- |
| The team has invented a trick to dodge it | The rule no longer describes how you work |
| Exceptions outnumber the normal case | The rule is written backwards |
| Nobody remembers who built it or why | Nobody will be able to judge whether it still makes sense |
| Its notice is filed unread | It no longer informs: it is noise |
| It creates work undoing what it did | It is subtracting, however much it looks like saving |

> [!IMPORTANT]
> The first row matters most and is looked at least: **when someone finds a way around a rule, the data starts lying without anyone lying**. If, to stop a notice firing, the team leaves a file in a state it should not be in, your reports reflect that workaround rather than reality. The automation has not merely stopped helping: it is distorting what you see. And you will not catch it on the dashboard, because the dashboard is precisely what has turned false.

## How to decide without arguing

1. **Look at how many times it fired last month** — Zero means retire it. Constant means look harder.
2. **Ask whoever suffers it, not whoever built it** — The one who configured it remembers it fondly; the receiver does not.
3. **Disable it for two weeks before deleting** — If nobody misses it, you have your answer.
4. **And note why it was retired** — It stops someone rebuilding it a year from now.

> [!WARNING]
> And one case deserves separate treatment: **an automation that reaches outsiders is not switched off without telling them**. If your suppliers have spent a year receiving an automatic reminder and it stops, they do not think you turned it off: they think the document is no longer needed. What is retired internally is simply retired; what went outwards is replaced by something or announced.

## What is worth reviewing once a year

**En corto**

- Which rules are active and who answers for each one today.
- Which have never fired: either the case does not occur or they are written wrong.
- And which fire every single time: that is no longer an exception, it is your normal process.

> [!NOTE]
> Switching an automation off is not admitting a mistake: what worked at twenty files a month can get in the way at two hundred. It would be odd if all of them still fitted two years on.

**Can it be disabled without deleting?**

Yes, and that is the way: if it turns out to be needed, switch it back on.

**What if it only annoys one person?**

Check whether that person is the heaviest user. Usually they are.

**How many should we have?**

As many as someone can explain. If nobody knows what one does, it is surplus.

## Ejemplos

**A team parks files in the wrong status to stop an automatic notice firing.**

- Disables the rule for two weeks and checks whether anyone misses it

→ Nobody misses it, and the statuses go back to saying what is actually happening.

**An automation has run for eight months and nobody knows whether it is still needed.**

- Checks how many times it fired last quarter
- Checks whether the process that justified it is unchanged
- Switches it off if it adds nothing, noting what it did

→ The system does what the company needs today, not what it needed a year ago.

**The automation annoys more than it helps.**

- Asks whoever receives it

→ The decision is taken with whoever bears it.

**It is switched off and something needed stops happening.**

- Notes what it did before switching it off

→ The gap is visible rather than discovered.

**It is switched off and nobody picks up what it did.**

- Assigns somebody what it was doing

→ Switching off leaves no orphaned work.

**It is kept just in case, without knowing whether it works.**

- Checks the run history

→ What works is what gets kept.

**Nobody knows who may switch it off.**

- Records an owner for each rule

→ The decision has an owner.

**It is switched off unannounced and somebody misses it.**

- Communicates the change before applying it

→ Nobody discovers the change through a failure.