You deleted it here. It is still there.

Automation is sold on the forward direction. A lead arrives, and it appears everywhere it should. An order is placed, and the spreadsheet, the accounts and the fulfilment list all learn about it within seconds.

Nothing about that arrangement runs backwards. Zapier says so directly: "Zapier does not support two-way syncing between apps. Zap workflows are one-way automations."

So the duplicate contact you deleted this morning is still sitting in the mailing platform. The cancelled order is still in the fulfilment sheet. The test records from setup are still in the accounting system, quietly included in a total somewhere.

Why nobody notices for months

Deletion is rare, and its consequences are delayed and diffuse.

Most days you create and update, which is what the pipes were built for. You delete something occasionally — a duplicate, a test, a cancelled booking, an employee record — and the immediate result looks correct, because you are looking at the system you deleted it in.

The evidence turns up later and somewhere else. A campaign goes to a list that is larger than your CRM says it should be. A stock count is off by the returns you removed. A report includes revenue from an order that was cancelled in March. Each of those gets investigated as its own small mystery, and the connection between them is never made, because the common cause is not an event — it is the absence of one.

There is a related trap in the same paragraph of the documentation: workflows process new data from the moment they are switched on, and do not bring across existing or historical records. So the gap runs in both directions. What existed before you connected the systems was never copied, and what you delete afterwards is never removed.

The tempting fix that makes it worse

The obvious response is to build a second workflow going the other way, so deletions propagate. The vendor's own warning applies here: two workflows pointing at each other risk an infinite loop, and a loop between two systems will burn through your task allowance faster than any legitimate use.

Loops aside, delete-propagation is genuinely dangerous. Deletion is the one operation with no undo in most tools, so a workflow that deletes automatically turns a single mistaken click into a permanent one, everywhere, in the time it takes to run. If you build it at all, it should be the narrowest possible rule with a human step in front of it — not a general mirror.

What actually works

Stop deleting. Start marking. Set a status — cancelled, archived, duplicate-of — instead of removing the row. Statuses travel through one-way automation perfectly well, because they are updates. This single habit converts an operation your pipes cannot express into one they can.

Filter on the status everywhere downstream. A cancelled order that still sits in the sheet is harmless if every report and workflow that reads it excludes cancelled rows. That is one condition per consumer, added once.

Name the system that decides existence. For each type of record — customer, order, product — one system holds the truth about whether it exists, the same way one system should own each field when two systems disagree about a value. Everything else is a copy that reports rather than decides.

Keep a delete checklist per record type. Four lines: to remove a customer, touch these systems in this order. It is not elegant, and it is the difference between a five-minute job and a half-remembered one.

Reconcile counts monthly. Contacts in the CRM versus contacts in the mailing platform. Open orders here versus open orders there. You are not looking for exact matches, you are looking for a gap that grows — a widening gap is the signature of deletions that are not travelling.

Clear out the setup debris deliberately. Test records made during building are the most common permanent residents, and they are usually in the system furthest downstream, where nobody looks.

The version of this that costs real money

Two cases are worth singling out, because in both the leftover copy does something rather than just sitting there.

The first is anything that sends. A contact deleted from the CRM but alive in the mailing tool will receive the next campaign — including, in the worst case, somebody who asked not to hear from you again.

The second is anything that counts. Stock, revenue, capacity. A deleted-but-not- everywhere record inflates a number that a decision gets made on, and the decision is wrong in a way nobody can trace back.

If you want the map of where your records live and which of them nothing can remove, that is part of a process audit: $299, three business days, and a written list per record type.

Related: when two systems write the same field, whose value wins settles the question for values. This one is the same question about whether the record exists at all.