How to write an automation rule you can undo

Everyone writes the first sentence when they set up automation: “if cost per acquisition goes thirty percent above target, pause the campaign”. The second sentence usually never gets written: “what happens if this rule fires wrongly, and how do I undo it?”

The difference between a rule with two sentences and a rule with one is that when the first misfires it is an incident, and when the second misfires it is a crisis.

Actions are not symmetric

Automation actions do not carry equal weight, and the distinction that matters most is reversibility. A paused campaign can be resumed, but the learning it lost does not come back. A changed budget can be set to its old value; the money spent cannot. A deleted ad set has no way back at all.

• Notification: fully reversible, the cheapest action there is. Every new rule should start here.
• Label or note: reversible, and it does not change the data.
• Budget change: the value can be restored, the spend cannot.
• Pause: technically reversible; the learning phase is not.
• Delete: irreversible. An automation rule needs a very good reason to delete anything.

Three familiar endings

One · The rule that reads delay as performance

Conversions do not land in the platform instantly. Server-side events can lag, and the attribution window may not have closed. A rule that reads the last three hours treats not-yet-written conversions as absent and pauses a campaign that is working fine. The fix is not a looser threshold but a window pulled back far enough for the data to complete.

Two · The rule that measures its own effect

A rule that raises a budget sees, on its next run, the results of the budget it raised. Cost climbs for a while because the campaign is adjusting; the rule reads that as decline, pulls the budget back, then raises it again. The campaign starts to oscillate. The way out is to give the rule a cooldown after its own change.

Three · The rule that quietly runs every day

This one is the most insidious. The rule works, nobody notices, nobody looks. Months later half the account is paused and no one knows when it started. The question to ask when a rule goes live is: when this fires, who finds out?

Four questions before you write it

1. In the worst case, what does this rule break — and does that cost money, time, or learning?
2. How long would it take me to notice that it broke?
3. What information do I need to restore the previous state, and is that information stored anywhere?
4. If I ran this in suggestion mode for a week, how many of its proposals would I have agreed with?

If the answer to the fourth is “I don’t know”, the rule is not ready to go live. That is what suggestion mode is for: reading a rule’s decisions before those decisions are real.