Marketing Cloud Connect sandbox masking is not something most masking tools touch, because they operate entirely inside Salesforce. You run your masking job, your Contacts and Leads look clean in the sandbox UI, and you move on. Meanwhile the Marketing Cloud Connect sync has already pushed the real names, emails, and phone numbers into synchronized data extensions on the Marketing Cloud side, where your masking tool has no write access and, in most setups, no visibility at all.
This is a structural problem, not a configuration mistake. Marketing Cloud Connect was built to keep Salesforce and Marketing Cloud in lockstep, and it does that job well. The trouble is that "in sync" means PII moves in both directions, and sandbox refreshes only reset one side of that relationship.
How the sync actually moves PII
Marketing Cloud Connect uses the Salesforce API to replicate records into Marketing Cloud Synchronized Data Extensions. Contact, Lead, and Campaign Member objects are the usual suspects, but custom objects enabled for Marketing Cloud often ride along too. Each sync writes real field values: email address, first name, last name, mailing address, sometimes phone.
When you connect a Salesforce sandbox to a Marketing Cloud business unit for testing, that sync runs exactly like production. It does not know the Salesforce side is a sandbox. It pulls whatever is in the Contact and Lead tables at sync time and writes it straight into Marketing Cloud, no filtering, no anonymization layer, no awareness that this is supposed to be a test environment.
If your masking job runs after the sync has already fired, the masked values never make it to Marketing Cloud. If it runs before the sync, you are better off, but only if the masked data stays referentially stable long enough for the sync to pick it up correctly and for downstream automations to resolve against it.
Where the real PII ends up
Once Marketing Cloud Connect has synced a sandbox refresh, the real customer data is sitting in several places that your Salesforce masking tool was never built to reach.
- Synchronized Data Extensions hold a direct copy of Contact and Lead fields, refreshed on whatever sync schedule the business unit uses.
- Journey Builder entry events can capture snapshots of subscriber data at the moment a contact enters a journey, independent of later changes to the source record.
- Automation Studio file drops and SFTP exports frequently include extracted subscriber data for list imports, often with no masking step built in.
- Email send logs and tracking data in Email Studio retain real recipient addresses and open/click history tied to those addresses.
- Einstein engagement scoring data trained on real subscriber behavior can carry identifiable patterns even after the source Salesforce data is masked.
None of these get cleaned up by a Salesforce-side masking tool. They sit in a connected GDPR-relevant system, fully populated with production PII, often accessible to a wider group of marketing and agency users than the sandbox itself.
Why this creates real regulatory exposure
GDPR does not grade on which system a personal data copy happens to live in. If a data subject's name and email exist in a non-production Marketing Cloud business unit connected to a sandbox, that is a processing activity subject to the same lawful basis and minimization requirements as production. Article 5(1)(c) data minimization applies whether the record sits in Salesforce or in a connected marketing platform.
Marketing teams tend to have broader access to Marketing Cloud business units than engineering teams have to Salesforce sandboxes. Agencies, contractors, and campaign specialists who should never see real customer data can end up building test journeys against live subscriber lists, simply because nobody flagged the sandbox-connected business unit as a privacy risk.
I have seen this pattern specifically in retail and financial services orgs where marketing operations treats the sandbox-connected business unit as a convenient testing ground. Nobody intends to expose PII. It happens because the sync just works, and working systems rarely get a second look from a compliance standpoint.
What masking Salesforce alone does not fix
Teams that have already deployed sandbox masking sometimes assume the problem is solved because their DSAR audits and internal reviews show clean Salesforce data. That confidence does not extend to Marketing Cloud, and auditors who know where to look will ask about it directly.
| Layer | Covered by Salesforce masking | Typical state post-sync |
|---|---|---|
| Contact/Lead records in sandbox | Yes | Masked, safe |
| Synchronized Data Extensions | No | Real PII intact |
| Journey Builder entry snapshots | No | Real PII intact |
| Automation Studio exports/SFTP | No | Real PII intact |
| Email Studio send/tracking logs | No | Real PII intact |
The gap widens with every sync cycle. A business unit connected to a sandbox that refreshes weekly can accumulate months of unmasked synchronized data, each pass layering fresh real records on top of whatever was already there.
Closing the gap without breaking Marketing Cloud testing
The fix starts with sequencing, not tooling you do not already have. Mask the Salesforce sandbox first, then trigger the Marketing Cloud Connect sync, so the data that actually reaches Marketing Cloud is already fake. MaskEzee runs as part of the sandbox refresh pipeline specifically so this order is enforceable rather than hopeful.
Second, treat Marketing Cloud business units connected to non-production Salesforce orgs as in scope for your data governance review, not as an afterthought. That means checking Synchronized Data Extensions after each sync, confirming Journey Builder test journeys are not running against real subscriber snapshots, and auditing who has access to that business unit.
Third, for teams that cannot guarantee sync timing, consider disconnecting Marketing Cloud Connect from sandbox orgs entirely and using static, pre-masked data extensions for marketing QA instead. It is less convenient than a live sync, but it removes the dependency on getting the masking-then-sync order right every single time.
Fourth, review Automation Studio file exports and SFTP drops on a schedule, not just when something looks wrong. These exports are often set up once and forgotten, quietly pulling real subscriber data into shared folders long after the person who configured them has moved to a different project.
None of this requires replacing Marketing Cloud Connect or slowing down legitimate marketing QA work. It requires acknowledging that the connector is a data pipeline with GDPR consequences, and treating the sync trigger as a masking checkpoint rather than a background process nobody owns.
Frequently Asked Questions
Does masking a Salesforce sandbox also mask data in Marketing Cloud?
No. Salesforce sandbox masking tools operate only on Salesforce objects and have no write access to Marketing Cloud Synchronized Data Extensions, Journey Builder, or Automation Studio. Once Marketing Cloud Connect syncs real PII into Marketing Cloud, it stays there untouched unless you mask the Salesforce data before the sync runs.
What is a Synchronized Data Extension and why does it matter for GDPR?
A Synchronized Data Extension is a Marketing Cloud table that Marketing Cloud Connect keeps aligned with a Salesforce object, usually Contact or Lead. It matters for GDPR because it is a separate copy of personal data subject to the same minimization and lawful basis requirements as the source record, regardless of which business unit it sits in.
Can I just disconnect Marketing Cloud Connect from my sandbox to avoid the risk?
Yes, and it is a reasonable option if marketing QA does not strictly need live sync data. Teams that disconnect typically load a static, pre-masked data extension for testing instead, which removes the dependency on masking timing but requires manually refreshing that test data periodically.
Does journey Builder keep PII even after the source Salesforce record is masked?
Often yes. Journey Builder can capture a subscriber data snapshot at the moment a contact enters a journey, and that snapshot does not automatically update when the source Salesforce record changes later. A masked sandbox record does not retroactively clean up journey entry data that was captured while the record was still real.
What is the correct order of operations for sandbox refresh with Marketing Cloud Connect enabled?
Mask the Salesforce sandbox data immediately after refresh and before any Marketing Cloud Connect sync fires, so only fake data ever reaches Marketing Cloud. Automating this sequence as part of the refresh pipeline, rather than relying on manual timing, is the only reliable way to keep real PII out of synchronized business units.