Right to be forgotten in Data 360: the Consent API, and why deleting a profile is harder than it looks

A customer emails to invoke their right to erasure. Simple request, legally binding clock. But the record you have to delete isn’t one record — it’s a unified profile that Data 360 stitched together from your CRM, your billing system, a marketing platform, and a web-behavior stream, resolved into a single Individual. Deleting “the customer” now means deleting the right rows across a modeled, identity-resolved data platform without leaving orphans, and without accidentally deleting the wrong person you over-merged six months ago.

This is the part of Data 360 that doesn’t make the keynote, and it’s the part that gets you fined if you fumble it. GDPR Article 17 and CCPA deletion rights don’t care that your data model is elegant. This post is the working mechanics of right-to-be-forgotten in Data 360: the Consent API that submits the deletion, the related-object rule that quietly decides what actually gets erased, the reprocessing schedule that means “deleted” isn’t instant, and the two ways a profile you forgot comes back to haunt you.

(One naming note: Salesforce renamed Data Cloud to Data 360 in October 2025. Older docs, endpoints, and the API itself still carry cdp/Data Cloud names — same platform. See the rebrand explainer for the history.)

Deletion goes through the Consent API

The first surprise is which door you use. In Data 360, a data-deletion / right-to-be-forgotten request is submitted through the Consent API — the same API that manages marketing opt-ins and opt-outs — using a specific action. The action that means erase this person is shouldForget.

The request identifies the individuals by ID, and for Data 360 it carries a mode that tells the API to act on the Data 360 profile rather than core CRM. The documented shape looks like this:

GET /services/data/v64.0/consent/action/shouldforget?ids=<Individual Ids>&mode=cdp&status=optin

A few things to pin down before you wire this up, because the details bite:

• mode=cdp is what scopes the action to Data 360. Leave it off (it defaults to normal) and you’re not acting on the Data 360 profile.
• The action is supported on API version 50.0 and later. Use a current version.
• You need ModifyAllData or the ConsentApiUpdate permission to call it — a high bar, correctly, because this is irreversible deletion.
• Verify the exact HTTP verb, parameters, and body against your org’s API version before you ship a client. The consent action resource is documented in the query-parameter form above, but there’s variation in how the Data 360 deletion call is expressed across versions and practitioner guides (some show a POST with a JSON body of records). Treat the pattern here as the shape, and confirm the specifics on the current Use the Consent API with Data 360 reference for your version. Getting this wrong on a deletion endpoint is not a bug you want to find in production.

If you’d rather not hand-roll the API, Data 360 also exposes a Data Rights Subject Request tool in the UI that handles deletion, restriction of processing, and data access/export, and gives you an audit trail — which is often the right call for a compliance workflow that auditors will want to see.

The related-DMO rule decides what actually gets deleted

Here’s the mechanic that separates a real erasure from a compliance gap. A shouldForget request deletes the specified individual record from the Individual DMO and the related DMOs — and the emphasis on related is the whole game.

Data 360 walks the relationships from the Individual DMO: the Contact Point Email, the Contact Point Address, the engagement records — anything modeled with a relationship path back to that Individual gets the person’s matching rows deleted, including the underlying Data Lake Objects mapped to those DMOs. That’s the behavior you want.

The trap is the inverse, and Salesforce states it plainly: data must be related to the Individual DMO to be included in the deletion; data stored in unrelated DMOs is not deleted. If you ingested a dataset that contains personal data but never modeled a relationship from it back to the Individual — a standalone support-transcript object, a loyalty-events table nobody linked — that person’s data survives the erasure request. It’s still there, still PII, and your deletion report says “done.”

So the real prerequisite for a defensible right-to-be-forgotten process isn’t the API call. It’s a data model where every object holding personal data has a relationship path to the Individual. Audit that first. The Consent API can only delete what your model says belongs to the person; anything orphaned from the Individual is invisible to it.

The unified-profile and data-space angle

Because the target is a unified Individual, the deletion reaches what identity resolution built: it removes the Unified Individual profile and the Unified Individual Link records that connect the source records to that profile, along with the source data mapped in. That’s correct behavior — you don’t want to delete the unified profile and strand the source rows that would just re-resolve into a new one.

Deletion also operates within the data space. If you run multiple data spaces — the hard partition that decides who unifies with whom — a request targets the individual in a given space. Where a person’s data lives in more than one space, that’s more than one deletion to reason about. (The per-data-space scoping is well-corroborated but lightly documented; confirm the current behavior against Salesforce Help before you treat it as a hard guarantee in a compliance runbook.)

”Deleted” is not instant — the 30/60/90 reprocessing

Do not tell your privacy officer the record is gone the moment the API returns 200. Deletion in Data 360 is not processed immediately — it “typically occurs within hours,” and longer with large volumes. That’s fine for GDPR’s one-month response window, but it means your verification can’t be a synchronous check right after the call.

The part that genuinely surprises teams: the request is reprocessed after 30, 60, and 90 days to delete any newly added data and verify full deletion. This exists because Data 360 is a living platform — between your deletion and the next data load, more of that individual’s data can arrive from a source stream. The reprocessing passes sweep up the stragglers and confirm the erasure held.

Two consequences to design for:

• The 90-day pass is your real “done.” Treat it as the verification checkpoint that full deletion completed, not the initial call. Build your audit evidence around the final pass, not the first response.
• Data can legitimately exist for that individual between passes. If an auditor pulls a record 40 days after your deletion and finds freshly-ingested data, that’s the system working as designed — the next pass catches it — not a failed erasure. Know this before someone panics.

The multi-system reality: Data 360 doesn’t cascade

This is the failure that turns a “completed” erasure into a breach report. Data 360 deletion does not cascade back to your source systems. Deleting a profile in Data 360 removes the ingested copies that live inside the platform — the DLOs, the DMOs, the unified profile. It does not reach into the origin systems — the actual Snowflake table, the source CRM record, the Marketing Cloud subscriber — and delete the data there. That’s deliberate: cascading deletes into every connected system would wreck source-system integrity.

Salesforce is explicit that you must submit deletion requests in every connected system and Salesforce cloud separately. So a complete right-to-be-forgotten process is:

1. Delete in Data 360 via the Consent API (or the Data Rights tool).
2. Delete in core CRM — where Privacy Center does the work (below).
3. Delete in each source system the data came from — the warehouse, the billing app, the marketing platform.
4. Delete anywhere it was activated or shared downstream — an audience already pushed to an ad platform isn’t retracted by deleting the profile.

Miss step 3, and the very next sync re-ingests and re-resolves the “forgotten” individual into a brand-new unified profile. This is the single most common way a right-to-be-forgotten process quietly fails: the profile is deleted, the source still holds the person, the pipeline runs tonight, and tomorrow they’re back — the reprocessing passes mitigate but can’t fix a source that keeps feeding the person in. Delete at the source, or the erasure doesn’t hold.

There’s a related edge for zero-copy / federated data: when Data 360 queries a source in place rather than ingesting it, there are no stored bytes inside Data 360 to erase — the data lives in the source and the deletion has to happen there. That’s an architectural implication of how federation works, not a special deletion feature, but it lands in the same place: for federated objects, the source system is where erasure actually occurs.

Consent vs. deletion: same API, opposite intent

Because both run through the Consent API, teams conflate them, and the difference is not subtle:

• Consent / preferences (optin, optout on actions like email or tracking) keep the data and limit its use going forward. An opt-out is a restriction, reversible, and the record stays.
• Right to be forgotten (shouldForget) removes the individual and related records permanently. It cannot be undone.

Opt-out is not delete. A customer who unsubscribes has not invoked erasure, and deleting them because they opted out is its own compliance problem. Map the request to the right action.

Where Privacy Center fits (and where it doesn’t)

Salesforce Privacy Center is the tool for the core-CRM half of the job. It lets you build Right to Be Forgotten policies (delete or mask), portability policies (export a subject’s PII for a DSAR), de-identification, and retention policies on core-cloud data. Its RTBF runs on a queue that processes roughly every 24 hours, is irreversible, and — mirroring Data 360 — re-checks deletions at 30, 60, and 90 days.

The boundary to hold in your head: Privacy Center handles core CRM; Data 360 goes through the Consent API; Marketing Cloud is handled separately. They are different products covering different stores. A complete erasure orchestrates all of them — which is exactly why the “submit in every connected system” rule exists, and why a mature privacy program treats right-to-be-forgotten as a coordinated workflow across surfaces, not a single button.

A defensible right-to-be-forgotten checklist

Pulling it together into what a team should actually operate:

1. Model for it. Every DMO holding personal data has a relationship path to the Individual DMO. Anything orphaned is invisible to shouldForget — find it before an auditor does.
2. Map the request to the right action. Erasure is shouldForget; a preference change is optin/optout. Don’t conflate them.
3. Delete everywhere the person lives. Data 360, core CRM (Privacy Center), every source system, and anywhere data was activated downstream. Deleting only in Data 360 without the source is how a profile comes back.
4. Verify at 90 days, not at the API response. Deletion is asynchronous and reprocessed at 30/60/90 days; build audit evidence around the final pass.
5. Confirm the specifics against current docs. Verb, parameters, per-call limits (bulk deletion is commonly batched — verify the current limit on the Data 360 limits page), and data-space scoping all shift by version. On an irreversible deletion endpoint, verify before you ship.
6. Keep an audit trail. The Data Rights Subject Request tool exists for exactly this — auditors want to see the request, the action, and the completion, not a cURL command in someone’s history.

Takeaways

• Erasure runs through the Consent API’s shouldForget action, scoped to Data 360 with mode=cdp, requiring ModifyAllData or ConsentApiUpdate. Verify the exact call against your API version — it’s irreversible.
• Only data related to the Individual DMO gets deleted. PII in unrelated DMOs survives the request. A model where every personal-data object links to the Individual is the real prerequisite.
• Deletion is asynchronous and reprocessed at 30, 60, and 90 days. The 90-day pass is your verification checkpoint, not the initial response.
• Data 360 does not cascade to source systems. You must delete in every connected system and cloud, or the next sync re-ingests and re-resolves the “forgotten” profile. Delete at the source.
• Consent ≠ deletion, and Privacy Center ≠ Data 360. Opt-out restricts; shouldForget erases. Privacy Center covers core CRM; Data 360 uses the Consent API; Marketing Cloud is separate. A complete erasure coordinates all of them.

Getting right-to-be-forgotten right is a data-model problem before it’s an API problem — and in regulated financial services and healthcare orgs, it’s the difference between a defensible process and a finding. Making a unified data foundation both useful and compliant is exactly the Data 360 work we do.