Right to erasure

Deleting the row is the easy part and the least important:

• Suppress future collection. If the source is a public page that is still online, the next crawl finds the same person again. Without a persistent block, erasure lasts until the next pass.
• Reach every copy. Data that has been distributed to customers or exported into other systems is still data you hold responsibility for. Cleaning only your own copy is theatre.
• Prove it happened. An erasure you cannot evidence is one you will have to argue about later.

To stop re-collecting a person you have to recognise them, and to recognise them you have to keep something. Retaining the address in plain text to enforce its deletion is self-defeating.

The standard resolution is a one-way hash. The address is stored as a digest, every candidate record is hashed and compared during collection, and matches are dropped — so the block is enforceable without the deleted address existing anywhere in readable form.

Three different requests, and conflating them causes real problems. An opt-out means stop sending to me and requires you to keep enough data to honour it. An erasure means stop holding me at all. A suppression list is the mechanism that implements the first and must never be the answer given to the second.

Handle both, keep them distinct, and make each one instant rather than a ticket. The cost of getting this wrong is regulatory; the cost of getting it right is a database migration and some discipline.

SalesShift's erasure endpoint records the address as a hash, deactivates the pool record and clears its contact fields, and flags and strips saved copies across every workspace — not only the one that made the request. The enrichment crawler checks that hash before every insert, so a re-crawl cannot restore the person.