---
id: KB-CL-015
url: https://app.codecontract.io/help/collaboration/an-automation-got-it-wrong-with-a-third-party
idioma: en
categoria: colaboracion
subcategoria: automatico
audiencia: usuario
nivel: intermedio
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-CL-013, KB-CO-008]
citadoPor: [KB-CL-019]
---

# An automation got it wrong with a third party

_A notice went out that should not have, and a client has already seen it. What to do, in order._

**Responde a:** a reminder was sent by mistake · an automatic rule notified the wrong person · cancel a send that already went out · apologising for a wrong automated notice

Sooner or later it happens: a rule fires on data that was not what you thought, and a reminder goes out to a supplier who had already delivered, or an expiry warning for something already renewed. The bad news is you cannot unsend. The good news is it is usually fixed in an afternoon if done in the right order.

## The order that works

1. **Switch the rule off first** — If it stays on, it is sending more while you write the apology. It is the most skipped step.
2. **Check how many people received it** — It changes the response entirely: one contact is not two hundred.
3. **Tell them before they ask** — One line, no technical excuses: what arrived, why it did not apply, and what to ignore.
4. **And fix the cause, not the case** — Correcting that one file and leaving the rule alone guarantees a repeat next month.

> [!IMPORTANT]
> The third step decides how the third party experiences it, and it is worth doing even when the error is harmless. A client who gets an odd notice and hears nothing more concludes your system sends things at random; the same client told within twenty minutes concludes you are on top of it. Same error, opposite readings.

## What NOT to do

| Not this | Why |
| --- | --- |
| Send another automated correction | If the first went wrong, the second arrives under the same suspicion |
| Explain the technical detail | The recipient does not care which rule it was; they care whether they must act |
| Wait and see if anyone complains | Those who do not complain read it too |
| Delete the trace of what went out | It is the only thing that lets you explain later what happened |

> [!WARNING]
> The nuance that surprises people looking at the breakdown: the correction **is also a send**, and counts as an action just like the mistaken one. If the wrong notice went to two hundred contacts, the apology is one more send, not two hundred — but the original error was already counted. Not a reason to skip correcting; very much a reason not to leave a misaimed rule running for days.

## How to stop it recurring

**En corto**

- Every new rule is tested on one or two cases first, not on the whole list.
- Rules that write to third parties should ask for confirmation at the start.
- And check how often it fired in the first week, which is when surprises show.

> [!NOTE]
> If the wrong notice had consequences — saying something had expired when it had not, or asking for documents already supplied — note it in that third party's file. If someone reconstructs the relationship weeks later, that note explains a message that would otherwise look like carelessness on your side.

**Can a send already out be cancelled?**

A signature request can be voided so the link stops working; an email already delivered cannot.

**Do I tell everyone or only those who reply?**

Everyone who received it: the others read it too.

**What if the agent did it rather than a rule?**

Same order. And review how far you had let it act.

## Ejemplos

**A rule sends expiry reminders to thirty suppliers who had already renewed.**

- Switches the rule off, checks the reach and tells all thirty the same day
- Fixes the rule's condition, not just the files

→ No supplier calls to ask, and the error does not repeat the following month.

**A rule sends a reminder to a supplier who had already delivered, and they phone annoyed.**

- Checks which rule fired it and on what condition
- Narrows the condition so it checks the status first
- Writes to the supplier explaining the error

→ The error is fixed in the rule and does not repeat with the other hundred and twenty suppliers.

**The automation sends a notice containing another supplier's data.**

- Stops the rule and checks the scope

→ The error is cut before it repeats.

**The error is discovered a week later.**

- Reviews the run history periodically

→ The fault is caught in hours.

**Nobody knows how many received the wrong notice.**

- Checks that rule's send log

→ Those affected are warned rather than everyone.

**The rule is fixed and whoever received it is not told.**

- Writes to those affected explaining what happened

→ The relationship does not suffer from silence.

**The whole rule is switched off over one case.**

- Narrows the condition instead of switching it off

→ What worked keeps working.

**The error repeats because nobody documented it.**

- Notes what happened and what changed

→ The next person does not reintroduce it.