Salesforce Consent Management: How to Manage Multi-Brand Opt-Ins and Opt-Outs?

One unsubscribe click. Two brands go silent.

A customer opts out of one brand's emails. Days later, alerts from a completely different brand stop showing up too — one he never touched.

Nobody removed him on purpose. The system just couldn't tell the two brands apart.

This is what a flat checkbox field does at multi-brand scale, and it's exactly the failure mode Salesforce Consent Management is built to prevent. 

This guide walks through one customer's unsubscribe, from opt-in to opt-out, using Salesforce's standard Consent Data Model — and why that model beats a custom-built alternative.

What Is Salesforce Consent Management?

Salesforce Consent Management is the standard data model that records a customer's opt-in and opt-out choices, instead of storing one flag per customer. It works by splitting every consent decision into four levels:

• Identity — who the customer is
• Brand — which business unit the choice belongs to
• Topic — which subscription or content stream it covers
• Channel — email, SMS, or another delivery method

That separation is what stops one opt-out from reaching a choice it shouldn't touch.

A field like HasOptedOutOfEmail on Contact or Lead works fine for a single-brand, single-channel business. It falls apart the moment a holding company runs more than one brand through the same org — an omnichannel grocery and electronics chain (call it Meridian Retail) alongside an independently branded e-commerce arm (Wavecart), for example. 

A customer opting out of Meridian's grocery promos shouldn't lose Meridian's electronics alerts or Wavecart's shipping notices, but a flat checkbox model can't guarantee that.

Rule Out a Custom Consent Object Before You Build One

The tempting shortcut is a custom object: one row per customer per brand, with a picklist for status. It's fast to build and easy to query.

It also means re-implementing everything Salesforce already ships for free:

• The native Consent API
• An audit trail on every status change
• Forward compatibility with Data Cloud segmentation, if the org ever needs it.

A custom object also has no natural way to express that consent lives at four different levels — an identity, a brand, a topic, and a channel-specific decision. Modeling all four onto one flat table means every new brand or channel forces a schema change.

The standard Salesforce Consent Data Model absorbs new brands and subscriptions as new rows, not new columns. That's the difference between a model that scales and one that gets re-architected in eighteen months.

The Salesforce Consent Data Model: Four Layers, Not One Flag

The model separates concerns into distinct entities instead of collapsing them into a single flag:

Each layer stays independent. A change at the subscription-consent level never has to touch the brand or identity records above it — exactly the isolation a multi-brand org needs.

Case Study: Setting Up Subscriptions Before Consent Begins

Take a customer, Priya, who engages with two of Meridian's brands. She's opted into three separate communication streams:

• Weekly grocery deals from Meridian Retail's grocery banner, by email
• New tech launch alerts from Meridian's electronics banner, by SMS
• Weekend fashion flash sales from Wavecart, by email.

The Identity and Brand Records

• Individual: IND_PRIYA_001
• Business Brand: BRD_MERIDIAN_01 (Meridian Retail)
• Business Brand: BRD_WAVECART_02 (Wavecart)

The Subscription Records

Each subscription is tied to a channel through the CommunicationSubscriptionChannelType junction object: the two email-based subscriptions map to Email, and the tech alerts subscription maps to SMS.

Because Priya opted into all three, her CommunicationSubscriptionConsent records all carry a status of OptIn — each against its own contact point and channel type.

How a Single Unsubscribe Moves Through the Model?

Priya decides she's getting too many grocery emails and clicks "Unsubscribe" from the Grocery Weekly Deals newsletter. She wants to keep her tech alerts and her Wavecart fashion deals untouched. Here's what actually mutates when that opt-out is processed.

What Doesn't Change: Individual and Business Brand

Priya's identity record and both brand records are structural entities, untouched by the transaction. This is what prevents a single unsubscribe from cascading into a broad-stroke exclusion across every brand she's connected to.

What Changes: The CommunicationSubscriptionConsent Record

This is the one record that changes. The system locates the record matching her identity, her contact point, and the Grocery Weekly Deals subscription channel, and updates it:

// Before
{
  "ConsentGiverId": "IND_PRIYA_001",
  "PrivacyConsentStatus": "OptIn",
  "CaptureSource": "Web Portal Signup",
  "CaptureDate": "2026-01-15T10:00:00Z"
}

// After
{
  "ConsentGiverId": "IND_PRIYA_001",
  "PrivacyConsentStatus": "OptOut", // mutated
  "CaptureSource": "Email Footer Unsubscribe Link", // mutated
  "CaptureDate": "2026-07-02T14:15:00Z" // mutated
}

Nothing is deleted. The prior state stays in the record's history, which is what makes this defensible during a regulatory audit rather than just functionally correct.

Confirm the Blast Radius Stays Contained

Walking through the surrounding records isn't decoration, it's the actual test of whether the architecture holds up.

Electronics tech alerts (SMS): stays OptIn. Even though this subscription sits under the same Meridian Retail brand as the grocery newsletter, the unique CommunicationSubscriptionConsent record per subscription means one unsubscribe doesn't touch its sibling.

Wavecart fashion flash sales (Email): stays OptIn. Even though Priya uses the same email address for this subscription as she did for the grocery one, the record is tied to an entirely separate Business Brand, so the retail unsubscribe event has no path to reach it.

If either of those had flipped, the model would have failed at the one job it exists to do. That's the check worth running in any implementation, not just trusting that the object relationships are correct on paper.

Three Practices to Apply When You Build This Yourself

• Use the native Consent API instead of custom SOQL. Writing Apex to walk every child subscription table before a marketing send is the same mistake as the custom-object shortcut — it works until a new brand or channel gets added, at which point every query needs revisiting. Salesforce's Consent API evaluates the Individual, Contact Point, and Subscription Consent hierarchy natively and returns a single aggregated answer.
• Enforce a deterministic CaptureSource on every opt-out. Every transition to OptOut should write a specific, consistent value — Preference_Center_V2_Footer, for example — rather than a generic label. Under GDPR or CCPA, the burden of proof for when and how consent changed sits with the organization, not the customer.
• Keep the UX simple and the data layer precise. A preference page can show a customer three clean brand toggles. Behind that simplicity, the API layer should still write to the granular CommunicationSubscriptionConsent table — one record per subscription and channel — not collapse the toggle into a single flag on the way in.

For the full object reference, Salesforce's Privacy Consent data model documentation lays out every entity and relationship in the model referenced above.

The Final Words

Consent problems rarely appear at the start. They usually surface later, when a new brand is added and an old setup begins affecting the wrong audience or creating questions that are difficult to answer.

A clear consent structure from the beginning helps avoid those problems.

At MIDCAI, we help businesses simplify consent management as they scale across Salesforce Data Cloud and Marketing Cloud Next. It is usually easier to fix the setup before the next brand joins.

Talk to our Data Cloud consultant about your current setup.

‍