Consent and the Right to Be Forgotten

🌐 Also in 28 languages

Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Image generated with AI

Module 5 of 6 in the chapter Data Quality and Governance, chapter 5 of the Data Architect course. Each module stands on its own. Previous: Privacy Laws Shape the Design · Next: Protect, Retain and Prove

The question this module answers: How do you design for consent, and for erasing a person?

Steve Trucking has a Recipient’s phone number. Simple question: can we text them? Maybe. About today’s delivery? Tomorrow’s? Can we use the number for a promotion? What if they said no texts, or yes to delivery updates but no to marketing, and then changed their mind?

Now the other direction. The Recipient says: delete my personal information. Where is it? Salesforce, probably, but we’ve learned that isn’t the whole answer. It came from a Retail Partner. It may be in a customer data platform, field history, an archive, a delivery note, an export, an integration log, an agent’s conversation. Consent and deletion sound like policy questions, but eventually the system has to answer them. That’s architecture.

Consent Is Data

The first principle: consent is data. Don’t reduce it to Has_Opted_In__c = true. The real question is never just “did they consent?” It’s consent to what, through which channel, at which address or number, for what purpose, when, has it changed, and can we prove it? If the business makes decisions on those answers, they have to be stored as structured data. A paragraph in a privacy policy isn’t enough, and neither is a checkbox on a web form: the checkbox captures an event; the architecture has to keep what the event means.

Use the Model Salesforce Already Built

My position: use the out-of-the-box consent model wherever you can, rather than rebuilding the same thing in custom fields. Salesforce’s consent data model manages consent at four levels, each a more specific question (Understand the Salesforce Consent Data Model (opens in a new tab)):

• Global consent, on the Individual: who is this person, and have they said no to everything?
• Engagement channel consent (Contact Point Type Consent): may we use this kind of channel, such as SMS or email?
• Contact point consent: what about this specific phone number or email address?
• Data use purpose: for what reason: delivery notifications, service, marketing?

Put together, the architecture can answer “may we use this person’s information, through this contact point, for this purpose?”, which is far more useful than “consent = yes.” Any record that relates to an individual can take part: leads, contacts, person accounts, users.

Click to enlarge

Four questions, each narrower than the last. A single opt-in flag answers none of them well.

Purpose Matters

A Retail Partner sends Steve Trucking a Recipient’s number so the crew can coordinate the delivery. That doesn’t make the Recipient a marketing lead. The same data can have different permitted uses: delivery coordination, service follow-up, marketing, AI personalization. If policy or law treats them differently, the model has to tell them apart. The question isn’t do we have the phone number? It’s what are we allowed to do with it?

And consent isn’t always the legal basis. Some uses rest on other grounds the law provides, and that’s Legal’s determination. Don’t build an architecture that assumes every privacy decision is an opt-in checkbox. Support whatever the policy says: if a use depends on consent, model and enforce consent; if another basis applies, still store what’s needed to decide whether the use is permitted.

Consent Has a Lifecycle and an Authority

People grant consent, withdraw it, change preferences, change numbers. The business adds new purposes; laws change. So design the lifecycle: what was chosen, when, how, for which purpose, and what happens on withdrawal. And here’s where it gets interesting: when a Recipient withdraws consent, Salesforce knows. Does the messaging platform? The analytics? The agent? Consent that lives in one system while others act on stale permission isn’t much of a control.

That means asking which system is authoritative for consent. Salesforce, a preference platform, somewhere else? Whatever the answer, don’t let five systems decide independently whether the same person agreed to the same use. Consent needs what any governed data needs: an owner, an authoritative record, a way to synchronize, and enforcement.

Now the Person Says: Forget Me

The first instinct is to delete the contact and call it done. But the person’s data may be on a contact, a delivery, a delivery note, a case, a photo, in field history, in Snowflake, in an archive, an integration log, a search index or an agent’s conversation history. That’s why my position on erasure starts earlier: deletion is rare and hard in practice, so control where personal data goes first. Design so it lands in as few places as possible. Then, when a request comes, obfuscate or de-link it where that satisfies the policy, and hunt down every copy: field history, archives, Data 360, and now search indexes and agent conversations.

Don’t start the hunt when the request arrives. By then it’s too late to begin understanding the landscape. Module 3’s dictionary, lineage and classification weren’t paperwork; they’re what make this possible. You already know which fields hold personal data and where the copies went.

Click to enlarge

A forget-me request is a decision for every copy.

The Clock Is Running

These requests come with deadlines. Under GDPR, the organization has to act on a person’s request without undue delay and within one month of receiving it; for complex or numerous requests that can be extended by two further months, but the person has to be told within the first month, with the reasons (Article 12(3), Regulation (EU) 2016/679 (opens in a new tab)). Other laws set their own deadlines; Legal will tell you which apply. Either way, a month isn’t long enough to discover the landscape. That’s the deadline the map of copies has to beat.

Delete, De-identify or Retain?

A request doesn’t necessarily mean everything everywhere disappears. Some records must or may be kept; some operational records can stay but stop identifying the person; some data can be de-identified. The applicable policy and law decide; the architecture supports each outcome, location by location: delete it, de-identify it, or keep it under an approved requirement (and then who may see it, for how long, why?).

Remember module 4’s distinction. De-linking counts as forgetting only when the person can’t reasonably be re-identified. Pseudonymized data is still personal data. Don’t use obfuscation as a shortcut around a legal requirement.

You Can’t Delete What You Can’t Find

Before you can erase someone, you have to find them. The request comes from an email address. One Retail Partner sent “Jane Smith,” another “J. Smith,” and the phone number changed. The Recipient isn’t a contact at all; their details sit on each delivery. The same person got deliveries for two different partners. One system knows them by email, another by an external ID. Erasure depends on identity, and you don’t want to delete someone else’s data because your matching was too aggressive. Identity architecture is part of privacy architecture.

Steve Trucking makes it harder still. One Retail Partner must never see another’s deliveries or Recipients. If the same person received deliveries for two partners, operations must keep those relationships apart, while privacy may still need to find the person across both. Don’t solve privacy by breaking the security boundary, and don’t protect the boundary by making privacy requests impossible. The architecture has to do both.

Photos and Free Text Are Data Too

It’s easy to think of privacy as fields: name, email, phone, address. But Steve Trucking takes millions of delivery photos a year, and some show people or the inside of a home. A retention or erasure policy that only looks at structured fields is incomplete; so is one that ignores files, documents, transcripts, logs, and AI prompts and responses.

And free text is dangerous. You remove the name, phone and address, then find this delivery note: “Call Jane at 602-555-0198. Gate code 4821. Dog is in the yard.” There it is. Classifying delivery notes as sensitive tells you there may be a problem; it doesn’t find and remove the personal data inside the text. Sometimes the best answer is to stop unnecessary personal details landing there at all. Control where personal data goes first.

Privacy Center Is a Tool, Not the Whole Architecture

Salesforce Privacy Center helps run these processes. Its right-to-be-forgotten policies are built per object, to capture everything you want removed, and run against a specific customer record (Delete Data with Right to Be Forgotten Policies (opens in a new tab)). That’s useful. But “we bought Privacy Center, so we’re done” isn’t an architecture. The person’s data may live outside any one tool’s reach: Data 360, the warehouse, partner systems, archives, logs, search, files, agent conversations. The enterprise still needs an enterprise answer, and you need to check what each tool actually covers before relying on it.

Portability and Proof

Some laws also give people the right to get a copy of their data. Notice it’s the same discovery problem: deletion asks where is this person’s data, so we can act on it? Portability asks where is it, so we can provide it? Both rest on identity, classification, lineage, the system inventory and ownership.

And then: how do you prove you did it? Request received, identity verified, systems searched, actions taken, exceptions recorded, retained data justified, completion logged. There’s a real tension here: you’re removing someone’s personal data while keeping enough evidence to show you handled the request properly. That’s exactly why architects shouldn’t invent retention rules on their own. Legal and compliance decide what evidence must remain; the architecture keeps it without keeping the data it was supposed to remove.

Beyond the exam: what AI changes. AI creates new purposes and new copies. Permission to use data to provide a service doesn’t automatically cover grounding an agent, personalization or training; Data Use Purpose is the natural place to tell those apart. And personal data can survive in prompts, grounding context, conversations, summaries, search and vector indexes, and logs. “We deleted the source record” isn’t a complete answer if the AI layer still remembers.

What an Architect Decides Here

• How consent and permitted use are modeled, so systems can answer who, which channel, which contact point and what purpose.
• Which system is authoritative for consent, and how withdrawals reach every system that acts on it.
• Where personal data can spread: fields, free text, files, history, analytics, archives, integrations, search and AI.
• How a request finds the right person and drives delete, de-identify or approved retention in each location.
• What evidence remains to prove consent and privacy requests were handled.

Consent and erasure look like opposites (may we use this data? can we stop and remove it?) but they rest on the same foundations: identity, purpose, classification, lineage, ownership, enforcement and evidence. Use the standard consent model, control where personal data goes, know where the copies are, and design the erasure process before the first request arrives. When someone asks “can you forget me?”, the architecture needs a better answer than “we think so.”

Explore

• Salesforce Help, Understand the Salesforce Consent Data Model (opens in a new tab), checked 2026-10-14.
• Regulation (EU) 2016/679 (GDPR) (opens in a new tab), Article 12(3), the deadline for acting on a request, checked 2026-10-14.
• Salesforce Help, Delete Data with Right to Be Forgotten Policies (opens in a new tab) (Privacy Center), checked 2026-10-14.