Marketing Cloud Next consent: the hidden cube

“We’ve imported all the opt-ins. So why did nobody get the email?”

If you’ve started a Marketing Cloud Next project, there’s a good chance you’ve heard that question already. Or asked it.

Consent in Marketing Cloud Next looks straightforward on the surface. A subscription, an opt-in, a send.

Cool, right?

But here’s the thing worth paying attention to with Marketing Cloud Next consent: it doesn’t behave like the opt-out checkbox many of us grew up with in CRM, or the All Subscribers list in Marketing Cloud Engagement.

It has more dimensions than that. It starts at “no”. And it only counts if it arrives the right way.

Salesforce has a whole Trailhead module on consent management for Marketing Cloud Next, plus a detailed help article on the consent tools and concepts. And there are some interesting details buried in them.

So, let’s have a look.

Marketing Cloud Next consent in a nutshell

If you only have 30 seconds:

• It’s a cube, not a checkbox: consent is stored per contact point (an email address or phone number), per subscription, per channel.
• The default is “no”: no opt-in record means the message doesn’t go.
• Channels have different rules: promotional email is checked, transactional email isn’t by default, and SMS, WhatsApp and RCS always are.
• It lives in Data 360: and it has to be written through the consent service, not mapped straight into the data model.
• Taking consent away has limits too: “unsubscribe from all” and SMS STOP are narrower than they sound.

The rest of this post is the detail behind those five lines.

First, what does Salesforce mean by consent here?

Salesforce says that Marketing Cloud Next manages all consent centrally using Data 360, with preferences stored as data model objects (DMOs).

The help documentation names four objects behind Marketing Cloud Next consent. Here’s what each one means in plain terms:

• Communication Subscription: the topic someone can subscribe to, like “Newsletter” or “Product updates”. A default “Marketing” subscription is created for you.
• Engagement Channel Type: the channel, such as email, SMS or WhatsApp.
• Communication Subscription Channel Type: a subscription on a specific channel, for example “Newsletter by email”.
• Communication Subscription Consent: the record that says whether a specific email address or phone number is opted in or out of that subscription on that channel, with the date and source.

Trailhead describes that last one as the record that “defines the ultimate truth”.

So that’s the one to keep your eye on.

The Marketing Cloud Next consent cube

The way I like to picture it is a 3-D table. A cube.

My first instinct was to call the three axes Contact — Subscription — Contact Point. But the documentation gives us a slightly more precise picture than that.

Salesforce says consent is “tied to the contact point value, as opposed to the Unified Individual record itself”.

So the person isn’t really an axis. The three axes are:

• Contact point: the actual email address or phone number.
• Subscription: the topic, like Newsletter or Offers.
• Channel: email, SMS, WhatsApp or RCS.

Each cell in the cube is one Communication Subscription Consent: opted in, opted out, or (most of the time) empty.

The person sits outside the cube. They connect to it through their contact points.

Salesforce’s partner workshop on consent describes four levels of consent, from the whole individual (Level 1) down to “a specific contact point value and a specific subscription type” (Level 4). Marketing Cloud Next supports Level 4, the most granular one.

That’s a pretty big shift.

• What consent belongs to: the email address or phone number, not the person.
• What carries across: nothing. Trailhead is clear that changing consent on one channel doesn’t affect the same subscription on another channel.
• Watch out for: new email addresses. If a customer changes their email address, Salesforce says the historical consent does not automatically transfer over. The new address needs its own consent.

Example scenarios

• Priya opts in to the Newsletter with her work email. Her personal email stays an empty cell, even though it’s the same person.
• A retailer’s “Offers” subscription runs on email and SMS. A customer opts in to email offers, and that says nothing about SMS offers.

No record, no send

Now this one is particularly interesting if you’re coming from Marketing Cloud Engagement.

Marketing Cloud Next consent uses strict opt-in. According to Trailhead, if there’s no record, “the system assumes they have opted out”.

Not “unknown”. Not “probably fine”. Opted out.

As the module puts it, “the sheer absence of a recorded ‘Yes’ is enough” to stop the message.

So most of the cube is empty, and empty means no.

How strictly that applies depends on the channel and the type of message. The help article explains that the consent check requires you to pick a communication subscription when you send, and makes sure each recipient is opted in.

• Promotional email: consent required.
• Transactional email: consent checks are disabled by default. Admins can change the settings in Setup.
• SMS, WhatsApp and RCS: consent required for any type of message.

And here’s the interesting part: for SMS, the partner workshop says the product “does not provide a mechanism to bypass SMS consent enforcement”. Even a delivery update needs an opt-in.

Example scenarios

• 40,000 CRM contacts are migrated without consent records. The first newsletter goes to almost nobody, because every cell is empty.
• An order-shipped SMS fails for customers who only ever opted in to email. SMS has no transactional exemption.

Marketing Cloud Next consent by channel

Here’s the same thing as a table, because it’s a lot easier to scan:

One nuance on transactional email: Trailhead says transactional emails don’t need a promotional subscription, but you should still respect global opt-outs. The workshop notes transactional email “may rely on a legitimate interest basis” under frameworks like GDPR.

That’s a legal call, not a technical one. Worth checking with whoever owns privacy on your project.

Consent has to travel through Data 360

This is the part that catches most teams out.

Marketing Cloud Next consent lives in Data 360. So far, so expected.

But it’s not enough for the data to land in Data 360. It has to get there through the consent service.

“Consent is just data in Data 360, so we can load it with a data stream.”

Well… yes. But the documentation gives us more detail than that.

According to the partner workshop, sends read from an internal consent service and cache layer. That’s how “consent changes are immediately respected at send time”. The Create Consent action, for example, updates that cache first, then writes the record into Data 360.

Data streams and batch data transforms can write to the Communication Subscription Consent DMO. But they don’t update the cache, so the send may never see the change.

Trailhead says it plainly: “Updating the data model object (DMO) directly does not update the consent for Marketing as expected.”

So, which routes are supported? Salesforce’s troubleshooting article lists them:

• Create Consent flow action: for forms, events and automation. It’s included by default in Signup Form campaign flows.
• Consent Status component: for updating one record by hand on the contact page.
• Consent Import: a CSV upload of up to 50,000 rows.
• More than 50,000 rows: stage the data in a custom DMO, then run a Data 360-triggered flow that calls Create Consent.

Preference pages and unsubscribe links are the built-in way for subscribers to change consent themselves.

Anything else, the article calls “an unsupported write path”.

• Older flow actions: Salesforce says not to use the MessagingConsent and MessagingConsentV2 flow actions. Create Consent replaces them.
• Delay: expect around 15 minutes before an update shows up in Data 360, according to the troubleshooting article. The send check itself reads the cache.
• Audit: a consent audit trail records every change, while the consent record itself only holds the current status.

Example scenarios

• Consent from a legacy ESP is mapped into the consent DMO with a data stream. It looks perfect in Data Explorer, but the sends don’t pick it up.
• A CRM opt-in field changes on a Contact. A record-triggered flow calls Create Consent so the change actually reaches Marketing Cloud Next.

Taking consent away

Taking Marketing Cloud Next consent away has its own nuances, and they’re worth knowing before a customer complaint teaches you.

• Unsubscribe links: every promotional email needs one, or a link to the preference page. A click sets the consent record to opted out.
• “Unsubscribe from all”: on the standard preference page, this removes the contact point from all existing subscriptions. Trailhead says it does not persist as a permanent block, so a subscription you create next month isn’t covered. (Though with default opt-out, nobody is opted in to it yet either.)
• SMS STOP: STOP, CANCEL and UNSUBSCRIBE are recognised, but STOP only opts out of that specific sender number, not all SMS from the brand.
• Deleting subscriptions: don’t. Salesforce warns that deleting a Communication Subscription permanently deletes all related consent history. Hide it from the preference pages instead.

Nobody wants to be the admin who tidied up an old subscription and took two years of consent history with it.

Example scenarios

• A customer texts STOP to your marketing short code, then still gets texts from your service number. Each sender number is opted out separately.
• A “Spring Sale 2025” subscription is no longer needed. Hide it from the preference page rather than deleting it.

So what should we actually take away from all this?

For me, the biggest takeaway is this:

“This contact is opted in” isn’t really a complete statement in Marketing Cloud Next.

Which address? For which subscription? On which channel?

When I’m working on Marketing Cloud Next consent, I’d ask four questions.

1. Which cell of the cube are we talking about?

Pin down the contact point, subscription and channel. If one of the three is missing, the answer is probably “not opted in”.

2. Does this message actually need consent?

Promotional email and anything on SMS, WhatsApp or RCS: yes. Transactional email: only if the check is turned on, and that’s a decision for your privacy team.

3. How is consent getting in?

Forms, imports, CRM sync, migrations. Every route should end in Create Consent, Consent Import or the Consent Status component, never a data stream straight into the DMO.

4. What happens when things change?

New email addresses, new subscriptions, STOP replies, retired topics. Each one has a rule, and none of them carry consent over for you.

The bigger picture

I really like where Salesforce has gone with Marketing Cloud Next consent.

Strict opt-in, per channel, per address, with an audit trail. That’s a privacy-first design, and it’s an essential foundation if you’re sending across email, SMS and WhatsApp at the same time.

But it does mean we need to change the question.

Instead of asking:

“Is this contact opted in?”

I’d ask:

“Is this email address or phone number opted in to this subscription, on this channel, and did that consent arrive through the consent service?”

That’s a much more useful conversation, especially early in a project, before the first send suppresses your whole audience.

Because, as we’ve seen, Marketing Cloud Next consent isn’t a checkbox. It’s a cube, it starts empty, and only the right tools can fill it in.

So the next time someone says, “But they’re opted in!”, you know what to ask:

“Well… opted in where?”

Curious how the AI side of the platform works? Read Smart features in the new Marketing Cloud Next.