Who Owns Consent When You’re Running Marketing Cloud Engagement and Next Together?

Running Marketing Cloud Account Engagement and Marketing Cloud Next side by side? A lot of Salesforce customers are doing exactly that right now – either by choice or because a migration stalled halfway through and the deadline got pushed. Either way, there’s a consent problem sitting underneath that setup that most marketing teams aren’t thinking about. 

Not a configuration issue. A structural one. 

The two platforms don’t share a consent layer. That’s the whole problem. And it carries real compliance exposure. 

What the Plus SKUs Actually Encourage You to Do 

When Salesforce restructured Marketing Cloud and pushed customers toward the Plus SKUs, the pitch made sense: run Account Engagement for B2B nurture, use Marketing Cloud Next for high-volume transactional sends and cross-channel journeys. One org, two tools, more coverage. 

That’s a legitimate use case. But the Plus packaging implicitly assumes you’re managing these as one unified operation – and the platforms weren’t built with a shared consent spine. 

Here’s the thing. Account Engagement handles opt-outs at the prospect level inside its own database. Marketing Cloud Next manages communication preferences through its own subscription management and contact data model. And the Data Cloud layer – which is supposed to be the unifying record of truth – doesn’t automatically bridge the two. 

So when a contact unsubscribes through an Account Engagement email, that opt-out lives in Engagement. Marketing Cloud Next doesn’t know about it unless someone built a sync to carry the signal over. 

Most teams haven’t built that sync. 

Where Consent State Diverges, Field by Field 

This is where it gets specific – because the divergence isn’t theoretical. It’s field-level, and it’s worth naming exactly what’s happening. 

In Account Engagement, the fields that matter: 

• Opted Out – the core email opt-out flag; true or false 

• Do Not Email – a harder suppression set by admins or import, not editable by prospects 

• GDPR Opted In – available on accounts using the GDPR features pack; a separate flag from Opted Out, which trips up a lot of teams 

• Prospect custom fields for preference center responses, if you built one 

In Marketing Cloud Next, what you’re working with: 

• Subscriber status at the All Subscribers level – Active, Unsubscribed, Bounced 

• Publication list subscriptions – opt-in at the list level, not contact level 

• Contact consent in Data Cloud when it’s in play – a separate object with its own data model 

• Preference center responses, stored in their own data extensions 

None of these are the same field. None of them sync automatically. Which is not fine – especially when you’re sending from both platforms. 

What happens in practice: a contact unsubscribes via a Marketing Cloud Next email, gets flagged as Unsubscribed at the All Subscribers level, and their Account Engagement Opted Out stays false. Then that contact gets enrolled in an Account Engagement nurture sequence – say, through a Salesforce CRM trigger or a list import – and email goes out. They already told you they didn’t want it. 

That’s not a worst-case scenario. That’s how the data model works unless you’ve explicitly wired the two systems together. 

The Compliance Exposure in Plain Terms 

GDPR doesn’t care which platform processed an opt-out. Consent is consent. A data subject exercised their right to withdraw, and you sent them an email anyway because the signal didn’t cross system boundaries. “We didn’t know the opt-out came in through a different platform” won’t hold up in an enforcement conversation. 

Under CAN-SPAM, the requirement is ten business days to honor an opt-out. If an unsubscribe processed in Marketing Cloud Next takes days – or never – to reach Account Engagement, that’s a violation. Simple as that. 

CASL is stricter still. Express consent must be positive and documented. If you can’t demonstrate that a contact’s opt-in is valid and consistently recorded across both sending systems, the burden falls on you to prove it. 

Worth saying: most auditors aren’t interested in your tech stack diagram. They want to see that a stated preference was honored. The fact that the gap was caused by vendor product architecture – not your team’s negligence – doesn’t protect you in an investigation. 

The compliance exposure here is real, and it’s sitting quietly in orgs running parallel platforms right now. 

The Manual Workaround and How It Fails 

Teams that have spotted this problem usually try to solve it one of two ways. 

Salesforce Flow or Apex. You build a trigger that watches for changes to Account Engagement’s Opted Out field and pushes a corresponding update to SFMC subscriber status – or vice versa. This works until it doesn’t. The sync is one-directional by default, so you need to manage both directions separately. Flows can fail silently. Apex requires maintenance. And the timing gap between opt-out receipt and sync execution is usually minutes, occasionally longer – which is long enough to get a send out the door in between. 

Data Cloud as the consent store. The idea is that contact consent in Data Cloud becomes the master record and both platforms read from it before sending. In theory, clean. In practice, this requires a consent data model that most orgs haven’t built, mapping rules that are genuinely complex to configure, and a real-time suppression check that adds latency to journey sends. 

To be fair, neither of these options is wrong. They’re just more fragile than the problem they’re solving. A homegrown sync that fails during a high-volume send period is worse than no sync – because you stop seeing the failure mode while the sends keep going out. 

A Governance Model That Survives Parallel Running 

If you’re running both platforms – or stuck mid-migration – the governance model needs to be architectural, not operational. Consent enforcement can’t depend on someone remembering to run a sync or check a report. 

Here’s what actually holds up: 

1. Designate one system of record for consent. Pick one. Data Cloud is the right answer if you have it provisioned and staffed. The Salesforce Contact record’s Email Opt Out field is a reasonable fallback if Data Cloud isn’t in play – but it requires every sending platform to check that field before sending, which requires custom configuration in both Engagement and Marketing Cloud Next. 

2. Build suppression lists, not sync rules. Rather than trying to keep opt-out flags in sync across systems in real time, maintain a suppression list that’s written to by any system receiving an opt-out – and checked by every system before a send runs. Suppression lists are append-only. They’re simple. They fail loudly rather than silently, which is exactly the failure mode you want. 

3. Map every opt-out entry point. Email links, preference center submissions, manual imports, Salesforce record updates, inbound unsubscribe processing. Every one of these writes a consent state somewhere. Document where, and document what happens to that signal next. If you can’t answer “where does this opt-out land and how does it reach both platforms,” the map isn’t done. 

4. Set a consent audit cadence. Monthly at minimum. Pull opted-out records from both platforms and the Salesforce CRM. Any contact opted out in one system and active in another is a finding that needs resolution – not a note in a ticket. 

5. Test suppressions before every major send. Not just after initial setup. Pull a sample of known unsubscribes and confirm they’re excluded from the send audience in both platforms. This should be pre-send QA, not an afterthought. 

That’s the model. Not glamorous. But it’s the one that doesn’t generate audit findings. 

What to Audit This Quarter 

If you’re running Engagement and Next in parallel and haven’t done a consent audit, this is where to start. 

Pull your full opted-out list from Account Engagement. Cross-reference against All Subscribers in Marketing Cloud Next. Any record opted out in Engagement but Active in SFMC is a suppression gap – suppress immediately and document it. 

Run the same check in reverse. SFMC Unsubscribed records showing Opted Out = false in Engagement need to be flagged too. 

Check your active journeys in Marketing Cloud Next. Any of them pulling entry contacts from Salesforce CRM objects – Leads, Contacts, Campaign Members – without an explicit suppression step? That’s a gap. 

Look at Account Engagement automation rules and engagement programs. Any of them using Opted Out = false as an inclusion filter? That’s correct behavior within Engagement, but it won’t catch opt-outs that came in through Marketing Cloud Next and haven’t synced. Most teams don’t catch this one until they’re looking for it. 

Document what you find. Not because documentation fixes anything – it doesn’t – but because an undocumented gap you discovered and didn’t act on is significantly harder to defend than one you found, logged, and are actively resolving.