Data 360
Consent in Data 360: modeling it, and filtering an activation so the opt-out sticks
A customer opted out, and the segment still reached them. That's almost never a bad segment. It's consent that was captured but never wired into the activation. Here's how to model consent as a Data Use Purpose and a Contact Point Consent DMO, and how contact point filtering makes the send drop the people who said no.
A customer unsubscribed last week, and this morning your campaign reached them anyway. The segment looks correct. The unsubscribe is right there in the source data. And the email still went out.
That gap is almost never a segmentation bug. Consent was captured, and it was never wired into the activation, so the send never checked it. In Data 360 that wiring is a specific thing you build, not a setting that protects you by default.
Consent here is three separate jobs, and teams that treat it as one get burned on the third. You have to capture consent, model it against a stable business reason, and apply it as suppression the moment an audience leaves for a channel.
The first two you probably do. The third, where an opt-out turns into a person dropped from a specific send, is the one that does nothing until you build it.
Consent is not the same job as deletion
First, clear up the confusion that sends people to the wrong feature. Consent and erasure both live under privacy, and they are different mechanisms with different objects.
A right-to-be-forgotten request deletes a person’s data through the Consent API’s shouldForget action. It removes rows. Consent management leaves the data in place and decides, per purpose and per channel, whether you may contact the person. One is destructive and final. The other is a filter you evaluate on every activation.
If your requirement is “erase this customer,” that’s the deletion path. If it’s “this customer opted out of marketing email but still gets transactional notices,” that’s consent, and it’s the rest of this post.
Model consent against a Data Use Purpose
Consent only means something when it’s attached to a reason. “The customer said yes” is useless until you can answer yes to what. The object that carries the reason is the Data Use Purpose: a stable, named business justification like Marketing Email, Product Updates, or SMS Promotions.
The Data Use Purpose is deliberately durable. Campaigns change, channels come and go, but “may we send marketing email” is a purpose that outlives any one journey. You define the purposes once, and every consent record points at one.
Consent status then lives on the Contact Point Consent data model object, tied to the individual’s contact points: the email address, the phone number, the postal address. A contact point is the reachable endpoint, and the consent record says whether that endpoint may be used for a given purpose.
Model it so the status and the Data Use Purpose sit directly on the Contact Point Consent DMO, as concrete values, rather than behind a reference you resolve at send time. The activation reads what’s on the record.
This maps onto the consent tiers practitioners label L1 through L4: L1 for essential, service-level processing, L2 for general marketing, and the two that matter most for compliance, L3 explicit and L4 verified explicit consent.
The labels are a practitioner convention rather than a formal product feature, but the distinction is real. Explicit and verified-explicit consent are the levels regulators care about, and the ones that used to force extra work.
Contact point filtering is what makes the opt-out stick
Historically, Data 360 handled the lower consent tiers natively and left L3 and L4 to downstream post-processing. You would activate an audience, then run the list through another system that stripped the people who hadn’t given explicit consent before anything sent. That step lived outside the platform, and when someone forgot to run it, the opt-out did nothing.
Contact point filtering, generally available since Summer ‘24, moves that job inside the activation. You apply a filter to the contact points in an activation so consent is evaluated as part of the send, and the platform brings L3 and L4 management natively into Data 360 instead of a bolt-on. An opted-out contact point is dropped where the audience is built, not in a script someone has to remember.
The mechanics are a filter on the activation, evaluated against the Contact Point Consent records. When you configure the activation, you point it at the consent DMO and set the condition: include this contact point only where consent for the relevant Data Use Purpose is granted. The activation then suppresses any contact point that fails the test.
Two design rules follow from that. Store the values you filter on, the consent status and the Data Use Purpose, as exact values on the consent DMO, so the filter is a clean equality check and not a join through a reference record.
And set the filter on every activation that reaches a marketable channel, because the filter is per-activation. Consent living in the data protects no one until an activation reads it.
Where suppression silently misses
The failure that reaches a customer looks like the filter didn’t work. Usually the filter was never there, or the consent record it needed hadn’t arrived.
The segmentation and activation path treats consent as a suppression that has to be wired into the activation itself. When suppression seems to miss, the usual causes are a consent record that hasn’t propagated into the unified profile yet, or a rule that’s present in the data but not attached to the activation. Both look identical from the outside: the person got the message. Neither is a model problem.
Freshness is the quieter half. Consent captured in a source system has to stream or batch into Data 360, resolve onto the unified individual, and land on the contact point before an activation can act on it. If the profile is running on last night’s load, a customer who opted out this morning is still marketable until the next refresh.
That’s the same data-freshness chain that decides whether any agent or activation is working on current truth. With consent, a stale profile is a compliance exposure, not the quality nuisance it looks like.
The consent posture worth holding
Treat consent as an activation-time filter you own, not a data attribute you hope someone respects downstream. Define durable Data Use Purposes, capture status onto the Contact Point Consent DMO as concrete values, and put a contact point filter on every activation that reaches a marketable channel.
That posture also feeds the rest of your governance. An agent grounded on customer data inherits the same question a marketer does: may it act on this person, for this purpose. The governance that scopes what an agent sees and the transparency obligations under the EU AI Act both assume a consent model that means something.
Contact point filtering is where “the customer said no” stops being a value in a table and becomes a person your send skips.
Understanding the basics
What is contact point filtering in Data 360?
Contact point filtering is a feature, generally available since Summer ‘24, that applies a consent filter to the contact points in a Data 360 activation. It evaluates consent as part of building the audience and suppresses any contact point that hasn’t granted consent for the relevant purpose. It brought native management of L3 (explicit) and L4 (verified explicit) consent into Data 360, work that previously required downstream post-processing outside the platform.
What is a Data Use Purpose in Salesforce consent management?
A Data Use Purpose is the stable, named business reason a person’s data may be processed, such as Marketing Email or SMS Promotions. Consent is meaningless without a purpose attached, because consent is always consent to something. You define purposes once, and each Contact Point Consent record references the purpose it grants or denies, so a customer can opt out of marketing email while still receiving transactional messages.
How is consent different from right to be forgotten in Data 360?
They use different mechanisms. Right to be forgotten deletes a person’s data through the Consent API’s shouldForget action and removes rows permanently. Consent management leaves the data in place and decides, per purpose and per channel, whether you may contact the person, enforced as suppression at activation time. Deletion is destructive and final; consent is a filter you evaluate on every send.
Why did an opted-out customer still receive my Data 360 activation?
Almost always because the consent filter was not wired into that specific activation, or the consent record had not propagated onto the unified profile yet. Contact point filtering is configured per-activation, so consent stored in the data suppresses no one until an activation reads it. Confirm the filter is on the activation, and confirm the opt-out has streamed in and resolved onto the contact point, before treating it as a platform fault.
Standing up a consent model on Data 360 that suppresses the right people, capturing purpose, resolving it onto the unified profile, and filtering every activation, so a marketing send and a grounded agent both honor the same opt-out? Talk to us. Getting the data foundation right before it reaches a customer is exactly the work we do.
