← All notes

A customer asks you to delete their data. Where is it?

4 min read

The email is three lines long and perfectly polite. Please delete my data.

The instinct is to open the CRM, find the record, delete it, and reply that it is done. The problem is that the CRM was never the only place their details lived. Every automation you built copied them somewhere: the spreadsheet the sales report reads, the mailing platform, the helpdesk, the invoicing tool, the backup that runs nightly. None of those copies notice that the original is gone.

The mechanical reason the copies stay

Automation platforms move data one way by design. Zapier states it plainly: "Zapier does not support two-way syncing between apps. Zap workflows are one-way automations."

One-way means every workflow you have is a small photocopier, and none of them has a reverse gear. There is no deletion event flowing back along the pipe, because the pipe only has one direction and it never pointed home. This is worth understanding before you promise anyone a deadline: the work is not one delete, it is one delete per system, and you need to know the list.

Three facts that surprise people

Deleting properly is not the same operation as deleting visibly, and platforms differ sharply. HubSpot is a useful example because its documentation is specific.

It cannot be done in bulk. "Permanent deletions can only be performed on individual contact records. You cannot perform permanent deletions in bulk using segments of contacts or workflows." One request is manageable. A list of forty, after a data incident, is a day of clicking.

It takes up to 30 days. The deletion is permanent but not instant, which matters if you have told someone it is already done.

The address becomes unusable afterwards. After a permanent delete, you "will not be able to add their email (primary or additional) back to your account in the future through HubSpot's UI or an import". They can still come back through a form on your site, an email to a connected inbox, or the API — and when they do, "a new contact record is created. The deleted contact's previous history, associations, and activity won't be restored".

Read that last one twice if you sell to returning customers. A person who asked to be forgotten in March and buys again in September arrives as a stranger, and your automations will treat them as one — including the welcome sequence.

What is deleted is also not everything: anonymised analytics data stays. That is usually the right answer legally, and it is the kind of nuance to know before you write a confident reply.

A route through it that does not depend on memory

Keep a standing list of where personal data lands. Not a data-protection project — a list, one line per system, written once and updated when you add a tool. If you already keep a register of what is automated, this is a column on it, and that is the whole job.

Follow the copies, not the systems. Walk the workflows outward from the first point of contact: form fills to CRM, CRM to mailing tool, orders to spreadsheet, spreadsheet to report, everything to the nightly backup. The copies are wherever an automation had an arrow.

Decide what you are allowed to keep before deleting. Invoices and tax records generally have to survive a deletion request; marketing history generally does not. Deleting something you were required to retain is its own problem, so this is a decision to make once, in writing, rather than per request.

Do the irreversible step last. Export what you must retain, deal with the copies, then permanently delete the master record. In that order, because the master is what tells you where everything else is.

Reply with what was done and what was kept, and why. "Deleted from A, B and C; the invoices for 2025 are retained because we are required to keep them" reads as competence. "All done" invites the follow-up you cannot answer.

Write down the date. If the platform takes up to 30 days, your reply should not imply otherwise.

What this says about how you build

Every new integration adds a place where a person exists, and therefore a place you will one day have to visit. That is not a reason to avoid automation. It is a reason to prefer designs where data has one home and other systems read from it, rather than designs where five systems each keep their own copy of a customer.

The same instinct pays off elsewhere: it is the difference between a clean answer and a guess when two systems disagree about the same field, and it is what makes a handover survivable.

If you would rather have the map than build it under time pressure, listing every place customer data lands and what a deletion request touches is part of a process audit: $299, three business days.

None of this is legal advice; obligations vary by where you and your customer are.

Related: how to keep track of every automation your business runs is the cheap version of the list this article says you need.