Skip to main content

Consent and activation: making the opt-out physically un-activatable

Segment logic is consent-blind: a segment built on behavior will include a person who opted out, and the activation will send them — unless consent is enforced at the activation boundary. This is where it gets enforced: Contact Point Filtering, backed by the Contact Point Consent DMO, filtering on consent status and data-use purpose so a non-consenting person is excluded from what ships. Cleon's stance is compliance by design — model consent alongside the data and make the safe path the only path.

Reference·Last updated 2026-06-01·Drafted by Lira · Edited by German Medina

A segment that targets the right people will still send to the wrong ones. The segment builder evaluates membership against behavior, attributes, and Calculated Insights — and none of that logic knows whether a person opted out. Build "customers who browsed but didn't buy" and the audience includes the person who unsubscribed last week, because nothing in the rule asked. The activation then ships that audience faithfully into the channel. The opt-out doesn't fail loudly; it rides along, invisible, until it lands in an inbox that explicitly refused it.

This page is the depth behind gotcha 4 and the mechanism behind principle 9: consent travels with the data, and a segment must be physically unable to activate a person into a channel they declined. The fix is not a filter someone remembers to add to each segment — it's structural, enforced at the activation boundary by a part of the platform built for exactly this. Here is what that part is, what backs it, and the discipline that makes it reliable instead of hopeful.

Why segment logic can't carry consent

Consent and segment membership answer different questions, and conflating them is the root of the failure. A segment answers who matches these rules — a population, evaluated against the unified profile. Consent answers what am I allowed to do with this person, in which channel, for which purpose — a permission, attached to a contact point. The two are orthogonal: a person can match every rule in a behavioral segment and still have revoked email permission, and a correct segment will include them precisely because matching the rules is all the segment was ever asking about.

You can bolt a consent check into the segment's own logic — add an "email opt-in = true" filter to the container and the audience narrows. Teams do this, and it is exactly the trap. It works until the segment somebody builds next quarter forgets the filter, or the campaign reuses an older segment that predates the rule, or a new channel ships and nobody adds the matching condition. The compliance failure is almost never malice; it is a segment nobody told about the opt-out. Consent enforced as a remembered filter is consent enforced by discipline, and discipline doesn't scale to every builder on every segment forever.

So the enforcement has to live below the segment — at the boundary where membership becomes an activation — where it applies regardless of how the segment was written or who wrote it.

The enforcement surface: Contact Point Filtering

In Data 360 (formerly Data Cloud) the boundary mechanism is Contact Point Filtering. When you configure an activation, after you select the channel and its contact point — the email, the phone number, the push token the destination keys on — the contact-point card exposes a filter. That filter is where consent is enforced: it evaluates each member's consent against conditions you set, and excludes the contact points that don't qualify from what actually ships. The segment can still contain the opted-out person; Contact Point Filtering is why that person doesn't leave the platform into the channel they refused.

The distinction is the whole point. The segment is consent-blind by design — it counts who matches. Contact Point Filtering is the consent-aware layer that sits between that population and the destination, so the audience that publishes is the audience minus everyone who isn't allowed to receive it. Membership and deliverability are two different facts, and the filter is the seam that keeps the second honest.

Segment            → who matches the rules            (consent-blind: includes the opt-out)
Contact Point      → the email / phone / push key     (what the channel sends to)
Contact Point Filtering → consent enforced here       (excludes the non-consenting contact point)
Activation         → what actually ships              (the audience MINUS who can't receive it)

What backs it: the Contact Point Consent DMO

A filter is only as trustworthy as the data it reads, and Contact Point Filtering reads consent from the model — specifically the Contact Point Consent DMO, the standard object that holds the consent record for a contact point. For subscription-level preferences (a person consented to this communication but not that one) there is a parallel Contact Point Subscription Consent object at the finer grain. These are where "did this person opt out" stops being tribal knowledge in some source system and becomes a modeled, queryable attribute the activation boundary can enforce against.

The filter evaluates two attributes that both live on that DMO:

  • Consent status — whether the person has opted in or opted out for the contact point. On the standard DMO this is the consent-status reference (ssot__ConsentStatusId__c), the field that distinguishes a live permission from a withdrawn one.
  • Data-use purpose — what the permission is for: marketing, analytics, a specific processing purpose. Carried as the data-use-purpose reference (ssot__DataUsePurposeId__c). A person can be opted in for one purpose and out for another, and "opted in" is meaningless without the purpose it attaches to.

Consent status is the attribute people reach for first; data-use purpose is the one that makes the enforcement correct. Filtering on status alone treats consent as a single on/off switch, when real consent is permission-for-a-purpose: the person who allowed transactional email but refused marketing is opted in and must be excluded from a marketing activation. The two attributes together are what let the filter honor that distinction — which is why both belong in the model, not just the easy one.

The discipline: model consent, don't remember it

Cleon's stance on this is compliance by design, and it is a modeling decision before it is an activation decision. Two things have to be true for the safe path to be the only path:

  1. Consent and data-use purpose are modeled alongside the data, populated into the Contact Point Consent DMO (and the subscription-level object where you need per-message granularity) the same way every other attribute is — so the enforcement surface has real, fresh data to read. Consent that lives only in a source system the activation can't see is consent that can't be enforced. The DMO is where it has to land (data model objects).
  2. Contact Point Filtering is applied as a standing convention on every activation into a consent-bearing channel, not a per-segment afterthought. The goal is that an activation into email cannot be configured to ignore email consent — that excluding the non-consenting contact point is the default shape of how activations are built here, so a new segment inherits the protection without anyone re-deriving it.

The reason to push this into the model and the convention, rather than into each segment's logic, is the same reason every other Data 360 discipline pushes leverage upstream: the failure you are guarding against is the one nobody is thinking about. A consent filter inside a segment protects that segment. Consent modeled on the contact point and enforced at the boundary protects every activation, including the one a teammate builds next year on a segment you never saw. Make the safe path the only path, and "did anyone remember the opt-out" stops being a question you have to ask.

This is also why consent is the thread that runs under the whole subcategory rather than a single page's concern. The target decision is exactly where it bites — a contact-point-keyed destination is where a non-consenting email would otherwise leave. Building a segment deliberately does not solve it, because solving it there would mean solving it once instead of structurally. And the Marketing Cloud bridge carries the same obligation across the platform seam: an opt-out honored in Data 360 has to stay honored in what the Journey receives.

What this page is not

This is the model and the enforcement pattern and the discipline — not a click-by-click setup. The exact steps to configure a contact-point filter, the permission set that lets you build one, the field-by-field mapping into the Contact Point Consent DMO, and how subscription-level consent is ingested are Salesforce-documented and version-specific; the references below are the canonical starting points. What doesn't change with the release notes is the shape of the thing: segment logic is consent-blind, the activation boundary is where consent is enforced, Contact Point Filtering is the surface and the Contact Point Consent DMO is what it reads, and the only durable version of "we honor opt-outs" is the one a builder can't forget because the model and the convention won't let the unsafe activation exist.

Related

Reference: