Managing Consent in Marketing Cloud Next: A Flow Builder's Guide

Why Consent Is Harder Than It Looks

If you've worked with Marketing Cloud Engagement, you're used to consent being relatively simple: a subscriber exists in a list, an opt-out status lives on a subscriber record, and the system honors it. The model is lightweight and, for years, it's been good enough.

Marketing Cloud Next takes a different posture. Consent is no longer a flag on a subscriber — it's a structured record with its own object, its own channel type, its own subscription reference, and its own cache. That sounds like overhead. In practice, it's the model that lets you answer compliance questions like "when exactly did this person opt into SMS for the Newsletter subscription, and through which channel touchpoint?" without reconstructing history from logs.

This guide walks through the consent data model in MC Next, explains the conceptual shift from MC Engagement, and shows you how to build a record-triggered Flow that captures consent correctly. We'll also cover the parts most walkthroughs skip: the 90-day cache gotcha, jurisdiction-aware opt-in, revocation handling, and what to do when consent records silently fail.

The Compliance Context

Before we get into the data model, it helps to understand why the model looks the way it does.

Modern privacy regulation — GDPR in the EU, CCPA/CPRA in California, LGPD in Brazil, PIPL in China, and a rapidly growing list of US state laws — has three common requirements:

1. Explicit, recorded consent for specific communication purposes
2. Auditable history of when consent was given, changed, or withdrawn
3. Channel-specific granularity — opting into email does not opt you into SMS

Marketing Cloud Engagement can satisfy most of these with careful configuration and custom build. Marketing Cloud Next bakes them into the data model. That's the shift: consent is now a first-class, auditable object rather than a derived attribute.

This is also why new leads and contacts arrive as opted-out by default in MC Next. If you're coming from MC Engagement, that default will catch you off guard. In MC Next, the absence of a consent record is the same as an opt-out. You must explicitly create a consent record to send a message.

The MC Next Consent Data Model

Let's walk through the objects that matter. The names are verbose, but each one plays a specific role. Here's the shape at a glance:

Communication Subscription

A Communication Subscription represents a purpose — why you're sending a message. "Newsletter," "Product Updates," "Shipping Notifications," and "Billing Alerts" are all separate subscriptions. A subscription is channel-agnostic; "Newsletter" might be delivered via email, SMS, or push depending on what the recipient has consented to.

Every subscription has an ID in the format 0XlAB00000001MMKAY.

Communication Subscription Channel Type

A Channel Type binds a subscription to a specific channel — Email, SMS, WhatsApp, or Push. So the "Newsletter" subscription actually has a Channel Type for Email and (potentially) another for SMS. Each Channel Type gets its own ID in the format 0eBAB00000001NNMAA.

This split matters for consent: you opt into "Newsletter via Email" as a distinct event from "Newsletter via SMS." The regulation requires it, and the model enforces it.

Communication Subscription Consent

This is the record that says "this specific contact point is opted in (or out) of this specific Channel Type." It's the object your Flow will create.

The Contact Point and the Party Identifier

MC Next doesn't key consent off a Lead or Contact record directly — it keys off a Contact Point (an email address, a phone number) and a Party Identifier (a reference to the Individual record that represents the human behind the touchpoint).

The Party Identifier is what makes consent portable. If the same person exists as both a Lead and a Contact, or as a record in Data 360 (formerly Data Cloud) with identity resolved across systems, the consent follows the Individual — not the CRM row. When you later build Segments in Data 360, consent checks happen against the Unified Individual, not a specific Lead ID.

The Privacy Consent Log

Every consent action — create, update, opt-out — is logged to ssot__PrivacyConsentLog__dlm, a Data 360 model data object. This is your audit trail. You don't write to it directly; it's populated by MC Next as consent records change. Bookmark this: when a compliance officer asks "can you prove this person opted in on March 14?", this is where the answer lives.

The 90-Day Cache (Read This Twice)

Here's the part that catches teams off guard.

As of early 2026 (documented by Pierre Mounier at The Agentic Marketer in January), MC Next does not read live consent at send time. It reads from a cache. When a send initiates, the system checks the cache for a consent record matching the recipient. If there's a hit, the cached value is used. If there's a miss, the system queries the live Communication Subscription Consent object, populates the cache, and uses that value for the next 90 days unless the underlying record is updated.

The cache is invalidated by specific paths:

• Manual update via the Consent Status widget on a Lead/Contact layout
• Click-through on an Unsubscribe link or Preference Center update
• A CSV import through the standard consent import tooling
• The Create Consent Flow action (the one you'll use below)

Direct writes to the Communication Subscription Consent DMO via API or SOQL may not invalidate the cache. That's the failure mode to watch: a record that looks opted-out in the object browser but still receives sends for up to 90 days.

The cache is a performance decision, not a compliance shortcut — but it's the kind of internal behavior that makes "it should work" and "it works at scale" different conversations.

The Consent ID Formula (The # Trick)

One of the more mechanical pieces of the MC Next consent model is the Communication Subscription Consent ID. This is the unique identifier for a consent record, and it's constructed — not auto-generated — from two pieces:

{ContactPointValue}#{CommunicationSubscriptionChannelTypeId}

So for an email consent to the Newsletter Email Channel Type, the Consent ID would look like:

jane@example.com#0eBAB00000001NNMAA

Why construct it yourself? Because this deterministic ID makes consent operations idempotent. If the same person is imported twice, processed through a Flow twice, or the same opt-in event fires from two systems, you don't end up with duplicate consent records — you upsert into the same row. That's a meaningful safeguard for compliance data.

In Flow, you build this with a formula resource:

{!$Record.Email} & "#" & "0eBAB00000001NNMAA"

One formula resource per Channel Type. If you have five subscriptions across email and SMS, that's ten formulas. A little tedious, but explicit is better than clever here — you want to be able to look at a Flow and see exactly which Channel Type is being touched.

MC Engagement vs MC Next: The Mental Model Shift

If you've been working in Marketing Cloud Engagement, the biggest adjustment isn't the syntax — it's the mental model.

The short version: in MC Engagement, consent is a property of the subscriber. In MC Next, consent is a relationship between a person, a purpose, and a channel — each with its own lifecycle.

Building the Consent Flow

With the model in hand, let's build a record-triggered Flow that creates a consent record when a Lead is created. I'll walk through the six pieces and flag the decisions that aren't obvious.

Step 1: Configure the Start Element

• Object: Lead (or Contact, depending on your model)
• Trigger: A record is created
• Optimization: Fast Field Updates is fine for the trigger itself — the actual consent write happens on a scheduled path
• Entry conditions: Exclude leads created by Marketing Cloud's own form submissions. Those forms already handle consent through their own mechanism, and you'll double-write if you don't filter them out.

A reasonable entry condition: LeadSource NOT EQUAL TO "Marketing Cloud Form". Adjust for your source tracking.

Step 2: Add a Scheduled Path

Here's a rough edge that's easy to miss: record-triggered Flows cannot make external callouts in the immediate-execution path. The Create Consent action's downstream pipeline to MC Next behaves as an async operation that doesn't play well with in-transaction triggers.

The fix is a scheduled path with a small delay — one minute after record creation is the community-standard pattern. This moves the consent write out of the triggering transaction and into a separate execution context where callouts are permitted.

Cleaner alternative: If your team is already working in Data 360, a Data Cloud Record-Triggered Flow on the Individual or Contact Point DMO can call Create Consent directly without the scheduled-path workaround. That's the architecturally blessed path; the scheduled path on a Salesforce record-triggered Flow is the workaround when you need to stay inside core CRM.

If you skip the scheduled path on a record-triggered Flow, your Flow will look like it's working in Setup but fail silently at runtime.

Step 3: Handle Jurisdiction (If You Need To)

Privacy regulations fall into two rough buckets that your Flow needs to handle differently:

Bucket 1 — Express / double opt-in required or strongly expected. The initial record creation is not sufficient consent; you must send a confirmation message and wait for the recipient to confirm before marking them as opted-in.

• Germany — UWG §7 and DSK guidelines effectively require double opt-in for marketing email
• Canada (CASL) — consent must be express and documented; double opt-in is best practice, not strictly mandated
• Other EU member states where national interpretation of ePrivacy leans toward double opt-in

Bucket 2 — Opt-out rights and universal signal handling. These regimes don't require double opt-in, but they do require clear opt-out mechanisms, honoring Global Privacy Control signals, and specific "Do Not Sell / Share" plumbing.

• California (CPRA), Virginia (VCDPA), Colorado (CPA), Connecticut (CTDPA), Utah (UCPA), and a growing list of US states
• Most of these let you mark a contact opted-in at creation time but require that opt-out is one-click, instantaneous, and respects GPC signals

Add a Decision element right after the scheduled path:

• Default outcome: Direct opt-in path (for Bucket 2 jurisdictions and anywhere without extra restrictions)
• Conditional outcome: "Express Consent Required" — Country is in Bucket 1, or other criteria your legal team provides

On the express-consent path, you don't create an OPT_IN consent record directly. Instead, you trigger a transactional confirmation email (a separate Flow or action), and the confirmation event fires a second Flow that writes the actual opt-in.

Get your legal team to sign off on the jurisdiction list. Privacy law is state-by-state in the US, changes frequently, and the wrong default can be expensive. This is not the place to improvise.

Step 4: Build Formula Resources for Consent IDs

For each Channel Type you'll be writing consent for, create a formula resource that concatenates the email (or phone for SMS) with a literal # and the Channel Type ID.

Email Newsletter consent:

{!$Record.Email} & "#" & "0eBAB00000001NNMAA"

SMS Shipping Notifications consent:

{!$Record.MobilePhone} & "#" & "0eBAB00000002QQRAA"

Name these resources descriptively: ConsentId_Newsletter_Email, ConsentId_Shipping_SMS. Your future self debugging this at 11 PM will thank you.

Step 5: Invoke the Create Consent Action

Drop in the Create Consent Flow action — this is the officially supported path per Salesforce Help article 005316463. You may also see MessagingConsent / MessagingConsentV2 in the action picker; these work but are not officially supported in record-triggered Flows and do not reliably invalidate the 90-day cache. Use Create Consent.

The key inputs:

Create one action element per subscription/channel combination you want to write. Yes, this gets verbose if you have many subscriptions — package it as a subflow once you've written it twice.

Step 6: Wire It All Together

The final Flow structure looks like this:

Activate it, create a test Lead that satisfies your entry conditions, and verify a consent record appears within about a minute.

Handling Opt-Outs and Revocation

Capturing opt-ins is only half the job. Revocation matters just as much, and regulations generally require that opting out be as easy as opting in.

Three patterns to have in place:

Inbound unsubscribe links. MC Next's send framework handles the one-click unsubscribe flow natively. The message includes a signed URL that writes an OPT_OUT consent record when clicked. You don't build this; verify it's wired up correctly in your email templates.

Contact-initiated opt-outs. When a person calls support or emails asking to be removed, a service agent needs a way to write an opt-out. Build a Screen Flow (or a quick action on the Lead/Contact) that takes the person's identifier and writes an OPT_OUT record for every Channel Type they're currently opted into. This is a great candidate for a subflow — package it once, call it from anywhere.

Bulk withdrawal for data subject requests. GDPR Article 17 ("right to erasure") and CCPA equivalents require you to process deletion/withdrawal requests within a defined window. For this, you want a batch process — typically an Apex-triggered job reading from a DSR queue — that writes opt-outs across all relevant Channel Types for a given Party Identifier.

Troubleshooting: When Consent Records Silently Fail

A few patterns we've seen cause mysterious "consent doesn't seem to be working" reports.

The Flow ran but no consent record appeared. Check the scheduled path actually executed — if you're on Fast Field Updates with no scheduled path, the Create Consent action may have failed silently because callouts weren't permitted. Add a Fault path to surface the error.

The consent record exists but sends still get blocked. Check the ContactPointValue on the consent record against the email on the outbound send. The match has to be exact — including case. A consent for Jane@example.com will not satisfy a send to jane@example.com unless your data hygiene normalizes everything before the consent is written.

The consent was updated but the next send still uses the old status. You may be hitting the 90-day cache. For testing, use a new email address so you know there's no cached value. In production, updates through the Create Consent action invalidate the cache — but if you wrote directly to the consent DMO via SOQL/API, you've likely bypassed invalidation.

Duplicate consent records appear. The Consent ID should be deterministic. If you're seeing duplicates, check that your formula produces identical output every time — trim whitespace, normalize email casing, and make sure you're using the right Channel Type ID for the right subscription.

Form submissions are creating double consent records. Your Flow is running on form-generated Leads. Re-check the entry conditions on the Start element.

Going Further

A complete consent architecture for MC Next typically includes more than a single record-triggered Flow. A few directions to explore once the basics are in place:

• A reusable Consent Subflow. Parameterize the subscription ID, channel type, and consent status as inputs. Call it from Screen Flows, record-triggered Flows, Apex, and scheduled jobs. One place to maintain.
• Bulk import path. For migrating legacy consent from MC Engagement or another platform, you'll want a CSV-driven import Flow or a Data Loader job that writes Communication Subscription Consent records directly. Pay close attention to the ConsentCapturedDateTime — preserve the original opt-in timestamp, don't stamp it with today's date.
• Surfacing consent on the UI. The Consent Status widget on Lead and Contact layouts is handy for service agents, but you may want custom LWC components that show consent across all subscriptions and channels for a given Party Identifier — not just the CRM record in front of them.
• Data 360 Segment integration. Once consent records are flowing cleanly, Data 360 Segments can filter by consent status as part of the audience definition. This closes the loop — Segments can only include people who actually said yes.
• Reporting and dashboards. Build a report or dashboard on the Privacy Consent Log so compliance and marketing can see opt-in/opt-out rates, sources, and trends over time.

Closing Thoughts

The MC Next consent model is heavier than what you're used to in MC Engagement. That's a deliberate trade. The weight buys you auditability, channel granularity, identity portability, and a defensible posture when regulators ask hard questions.

Get the Flow right once, package the pieces as subflows, and the day-to-day work stays manageable. Skip the details — especially the scheduled path, the deterministic Consent ID, and the cache behavior — and you'll spend quarters debugging "consent isn't working" tickets that are really data model mismatches in disguise.

The good news: this is a model you only have to learn once. And once it clicks, most of the edge cases that used to require custom MC Engagement glue just… aren't edge cases anymore.

Further Reading

• Understanding Consent Concepts in Marketing Cloud Next — Salesforce Help
• Marketing Cloud Next Supported Consent Actions — Salesforce Help (read this before choosing an action)
• Privacy Consent Log DMO reference — Salesforce Developers
• How to Create Marketing Cloud Consent Records with a Record-Triggered Flow — Lauren Doerr (the de-facto primary build reference for the Flow pattern in this guide)
• Consent Management in Marketing Cloud Next Explained — Pierre Mounier (source for the 90-day cache behavior)
• Create Consent Records with a Subflow — Nobuyuki Watanabe
• Privacy Consent Design in Marketing Cloud Next — Shashi Prasad