What Salesforce Isn't Telling You About MC Next CONSENT Convergence, And How To Solve It
How to navigate consent architecture during your Marketing Cloud Next migration. Four real-world scenarios and the solutions that actually work.
What Salesforce Isn't Telling You About MC Next CONSENT Convergence, And How To Solve It
If you're running Marketing Cloud Engagement, Account Engagement, or both - and you're planning to migrate to MC Next - your consent architecture is about to become the most important decision you make this year. Get it wrong, and you're choosing between two equally terrible outcomes: campaigns that silently refuse to send, or campaigns that blast contacts who've already unsubscribed. The first one costs you revenue. The second one costs you possible fines from ACMA.
I've spent the last few months untangling a variety of consent convergence scenarios across financial services, non-profit, airline and retail organisations. The pattern is depressingly consistent. So let me walk you through the four scenarios I see in the wild, what each one means for your migration, and the best-practice solutions that actually work today, along with a few honest caveats about what doesn't work yet.
Glossary of Acronyms
I'm going to use a lot of acronyms in this article. Because the Salesforce product team LOVE rebranding their products annually.
The Fundamental Problem Nobody Warned You About
MCE and MCAE both operate on an implicit opt-in model. You create a subscriber record, and they're contactable. Unsubscribes are handled retroactively - someone clicks a link, a boolean field flips, done. It's simple, it's familiar, and it's served us well for 15 years.
MCA flips the entire model on its head. Every contact starts in an opt-out state. Explicit, verified opt-in must exist before the system will dispatch a single message. And consent isn't managed at the contact record level anymore, it's managed at the Contact Point level. That means the specific email address or phone number. If a customer updates their email, a new consent record must be created for that new address before marketing can resume.
This isn't a configuration option. It's the architectural foundation of the platform. And if you're running old and new Marketing Cloud in parallel - which, let's be honest, is what every existing Marketing Cloud customer is going to do, you've got two systems with opposing views on whether your customers have consented to hear from you.
But, that's just where the fun begins.
Scenario One: Consent Mastered in MCE
This is a common pattern I see in B2C organisations. Your MCE All Subscribers table is the source of truth. Publication Lists (often) manage channel preferences. Consent updates happen inside MCE, and the CRM either gets a delayed sync or doesn't get updated at all.
It works fine when MCE is your only marketing platform. The moment you provision MCA alongside it, you've got a problem.
MCA can't peer into MCE's isolated database for real-time consent checks. MCA queries the MCA consent data model (sitting in Data 360) exclusively. If the opt-in only exists in MCE's All Subscribers list, the send fails silently. Your marketing team sees a perfectly configured campaign with zero deliveries and no error message that actually explains why.
Now here's the part that makes this scenario particularly tricky: syncing consent back from Data 360 into MCE is not straightforward. You might think you could build a bidirectional pipeline, where consent updates flow out of MCE into MCA, and MCA consent changes flow back into MCE. There is no native solution that supports this.
The better solution, and the one I recommend to every client in this position, is to stop using MCE-native audience selection entirely and drive all your MCE campaigns and journeys from Data 360 segments and activations. When you use a Data 360 segment as your insertion source, the segment itself can respect MCA's consent model at the point of audience evaluation. The consent check happens before a contact ever enters the journey, which means you don't need to solve the backward sync problem at all. MCE becomes the execution engine. Data 360 becomes the consent-aware brain.
But you still need to get your existing MCE consent data into MCA in the first place. The approach that actually works is to extract your MCE consent preferences into a Data Extension, ingest that DE as a Data Lake Object in Data 360, and then trigger a Flow that writes the corresponding consent records into MCA's consent data model. You might look at this and think "surely I can just map the DE DLO directly into the DMO consent data model objects", it looks like it should work. It doesn't. There's a caching issue that breaks the mapping, and I've watched multiple teams burn days debugging it before discovering it's a known limitation. Build the Flow. It works. The shortcut doesn't.
Noting that you need to do this to consider opt outs from your MCE Preference Centre, Mobile Studio (SMS and Push), if somebody opts out using Google's native Unsubscribe feature, and if the customer simply replies to the email with "Unsubscribe".
My honest advice: MCE as consent master is a viable transitional state, but only if you commit to the Data 360 segments approach for all MCE Campaigns and Journeys. That's a significant operational change for your marketing team, they need to stop building audiences in MCE and start building Segments in Data 360. It's a change management challenge as much as a technical one, but it's the cleanest path through.
Confused yet? It certainly gave me a nosebleed.
Scenario Two: Consent Mastered in CRM Fields
This is the "default" pattern, and I see it everywhere in CRM-driven organisations. Someone, at some point, decided that the standard HasOptedOutOfEmail field on Person Account, Contact and Lead was where consent should be mastered - and rightly so. Maybe they added a few custom fields — Global_Newsletter_Opt_In__c, SMS_Consent__c, that sort of thing. The CRM became the consent master, MCE and MCAE synced 2-way to those field values, and everybody is happy.
For simple B2B email marketing with a single channel focus, this actually works. I've seen clean implementations where a Pardot prospect's HasOptedOutOfEmail value syncs reliably, the nurture campaigns respect it, and the sales and service teams have real-time visibility and option to edit consent status from the record page layouts. No drama.
Mapping these fields into Data 360 DLO is easy enough, but the challenge comes if you want to retain the ability to keep those fields updated if somebody opts out from an MCA Preference Centre.
The migration path: The best solution here is a clean break. Migrate your existing CRM consent field values into MCA's native consent data model, build a one-time migration Flow that reads the current field states and creates the corresponding Communication Subscription Consent records in MCA. Once that migration is complete, hide the old consent fields from your page layouts. Don't delete them, you might need them for audit history, but remove them from active use so nobody's maintaining consent in two places.
Then deploy the CRM Consent Component on your Contact, Lead, and Person Account page layouts. This new CRM Page Layout Component gives your CRM users a native interface for managing consent that fetches and writes directly to MCA's consent data model. Sales reps and service agents can still manage customer preferences from CRM with the same workflow they're used to, but the underlying data is now mastered in the architecturally correct location.
One critical note: Person Account support for the CRM Consent Component was only released in February 2026. If you're a B2C organisation running Person Accounts, and in financial services and retail across APAC, that's most of you, this feature literally wasn't available until two months ago. If you evaluated this approach earlier and ruled it out because Person Accounts weren't supported, it's time to revisit.
And if MCE is still in the picture during your transition, apply the same pattern from Scenario 1: drive all MCE journeys and campaigns from Data 360 segments so the consent check happens at the Data 360 layer, not inside MCE.
My honest advice: CRM field-based consent should be treated as legacy debt. The CRM Consent Component gives you a clean migration path that preserves the user experience your sales and service teams are used to while putting consent data where it actually needs to live. Do the migration, hide the fields, move on.
Scenario Three: Consent Mastered in the Salesforce Individual Consent Model
This is the enterprise-grade approach, and when it's implemented properly, it's genuinely impressive. Salesforce's native Individual consent data model uses ContactPointConsent records linked to DataUsePurpose objects, with full consent source attribution, capture timestamps, and effective date ranges. It's the architecture that was designed for exactly this problem.
I worked with a global organisation headquartered in Australia that implemented this model across their entire Salesforce estate. Multi-channel consent: email, SMS, mail, with full GDPR compliance. Every consent record tracked where it came from (web form, phone call, branch, third-party partner), when it was captured, and when it expires. Their legal team could pull a complete audit trail for any contact in under thirty seconds.
You'd expect this scenario to be the cleanest migration path to MCA. And conceptually, the alignment is strong. Both models use contact-point-level consent with purpose attribution. But here's the uncomfortable truth: the Individual consent model does not map exactly to MCA's consent data model. Despite the apparent structural similarity, there are enough differences in how the two models handle consent scope, channel attribution, and status values that a direct mapping isn't possible.
The only known solution today is to build Flows going both ways. One Flow that reads Individual consent records and creates or updates the corresponding MCA consent records, and a second Flow that captures MCA consent changes (from Agentforce interactions, preference centres, or marketing touchpoints) and writes them back to the Individual consent model. This keeps both systems synchronised, but I won't pretend it's elegant. It's not seamless, it requires careful error handling, and you're maintaining two parallel consent stores with custom automation bridging the gap.
My honest advice: If you're on the Individual consent model, you're architecturally more mature than most organisations I work with, and that maturity will serve you well long-term. But the dual-Flow synchronisation pattern is a pragmatic workaround, not a permanent solution. Build it, test it thoroughly, monitor it closely, and keep an eye on the Salesforce release calendar, because native syncing support is on the roadmap (more on that below).
The MCAE Question
I need to address Pardot specifically, because the migration path from MCAE has its own wrinkles.
Pardot's consent model was always simpler than MCE's. Prospect records had a DoNotEmail field, and that was largely it. The Pardot-to-CRM sync connector handled the bidirectional updates between DoNotEmail and HasOptedOutOfEmail, and most organisations treated the CRM as the consent master with Pardot as a downstream consumer.
The good news is that this simplicity actually makes the MCAE / MCA convergence more straightforward. You're essentially migrating from Scenario Two (CRM fields as consent master), and the CRM Consent Component migration pattern I described above applies directly.
The less good news is that MCAE's sync connector is being deprecated as part of the broader MCAE-to-Marketing-Cloud-Next transition. The batch sync model gets replaced entirely by real-time Data 360 segment activations. That means your consent data flow needs to be re-engineered from scratch regardless, the old plumbing is being ripped out whether you're ready or not.
If you're running Pardot and MCE in parallel (and I see this more often than you'd think, usually the result of an acquisition or a B2B/B2C split), you've got the most complex convergence scenario of all. Two legacy systems with different consent architectures, both feeding into a new platform with a third, incompatible consent model. My strong recommendation: designate a single consent master, consolidate there first, and then migrate to MCA. Trying to synchronise three consent models simultaneously is the kind of project that ends marketing careers.
The Parallel Operations Trap
Here's the scenario that trips up even experienced architects: the 6-to-18-month transition period where you're running MCE or MCAE alongside MCA.
During this window, you have campaigns firing from both platforms. A customer could receive an MCE email at 9am and an MCA-triggered campaign at 2pm. If consent is mastered in one system but the other doesn't have real-time visibility, you're flying blind on compliance for half your communications.
The three things that will save you during parallel operations are ruthlessly boring, and I make no apologies for that.
First, designate one system as the consent master from day one. Not "we'll figure it out later." Not "both systems are authoritative." One master. Everything else subscribes.
Second, move all MCE and MCAE campaigns to Data 360 Segments as the source. I keep coming back to this because it's the single most impactful architectural decision you can make during the transition. When both your legacy and new platforms are sourcing audiences from the same consent-aware Data 360 segments, you've eliminated the consent synchronisation problem at the audience layer. It doesn't matter that MCE and MCA have different internal consent models, neither system is making the consent decision anymore. Data 360 is.
Third, build your consent ingestion pipeline before you send a single campaign from the new platform. The temptation to launch a pilot campaign from MCA before the consent data is fully migrated is attractive, but stupid.
What's Coming (and What to Watch For)
Here's where I want to inject some measured optimism. The solutions I've described above - the Flow-based adapters, the Data 360 segment approach, the CRM Consent Component migration, are the best-practice answers for right now. But Salesforce knows these gaps exist, and the release cadence is coming fast and heavy.
There are strong signals, and I want to be clear these are informed rumours at this stage, not confirmed features, that upcoming releases may include native solutions for the two biggest pain points: MCE Distribution List syncing with MCA's consent model, and CRM Individual Consent syncing directly into MCA without the dual-Flow workaround. The releases to watch are June 2026, September 2026, and February 2027.
If these ship as expected, the consent convergence problem becomes dramatically simpler. MCE-mastered consent would sync natively. Individual consent model deployments would have a supported integration path. The custom automation I've described in this article would become unnecessary.
But they haven't shipped yet. And I've been in this ecosystem long enough to know that roadmap items sometimes slip, sometimes change scope, and sometimes quietly disappear. So build for today's reality, design for flexibility, and keep a close eye on the release notes.
What I'd Do If I Were Starting Tomorrow
If a client called me right now and said "Robin, we're moving to Marketing Cloud Next and we need a consent strategy," here's the conversation I'd have.
If they're a mid-market B2B shop running Pardot with simple email consent in CRM fields, I'd tell them to migrate those field values into MCA consent, deploy the CRM Consent Component, hide the old fields, and move to MCA in a clean swap. Don't over-engineer the transition, just do it.
If they're running MCE with complex multi-channel consent, I'd build the DE-to-DLO-to-Flow ingestion pipeline to get their consent into MCA, switch all MCE campaigns to Data 360 segment-driven execution, and plan the full MCA transition with consent already in the right place when they get there.
If they're already on the native Individual consent model, I'd buy them a beer and acknowledge they've done the hard architectural work. Then I'd build the dual-Flow synchronisation, flag it as a temporary measure, and set a calendar reminder to check the June '26 release notes for native syncing.
And if they're running both MCAE and MCE, honestly, I'd pour something stronger than beer and have a very frank conversation about consolidation timelines.
The brutal truth about consent convergence is that it's not a technical problem. It's an architectural decision that has legal, commercial, and operational consequences, and most organisations are making it by accident, or not making it at all, and hoping nobody notices.
Someone's going to notice. It'll either be your compliance team, your regulator, or your customers. Best to get ahead of it.
I am optimistic. The Salesforce release cadence suggests native solutions are coming, possibly within the next twelve months. But "coming soon" doesn't help you if your migration is happening now. The gap between where the platform is today and where it's heading is exactly the space where you need expert advice to navigate safely.
If you're staring down a Marketing Cloud Next implementation and your consent architecture feels like it's held together with sticky tape and optimism, you're not alone. But the worst thing you can do is guess. Get someone in who's seen all four scenarios, understands the current limitations, and can architect a solution that works today while staying flexible for what's coming tomorrow.
What's your consent master right now? And more importantly, does your migration plan actually account for it? I'd genuinely love to hear what you're dealing with in the comments.
