Experience Cloud sandbox masking usually stops at Contact and Account records, which leaves portal user data, guest account activity, and self-registration fields sitting in plain text. That gap matters more than most admins assume, because Experience Cloud sites store identity data in places a standard masking policy never looks. Partners, customers, and anonymous site visitors all leave PII behind, and a sandbox refresh copies every bit of it into a lower environment with weaker access controls.
What Experience Cloud Sandboxes Actually Copy
A sandbox refresh doesn't distinguish between your internal Salesforce org and the Experience Cloud sites layered on top of it. Every community, portal, and site gets copied along with its full data footprint: User records for external members, NetworkMember junction records, ContactPointAddress entries tied to portal logins, and site-specific custom objects built for self-service forms.
Most GDPR masking checklists are written around Lead, Contact, and Account. That works fine for sales data. It falls apart the moment a company runs a customer portal or partner community, because those sites generate their own parallel set of PII-bearing records that live outside the standard sales objects.
I've reviewed sandbox builds where the masking job ran clean on every standard object, yet the Experience Cloud site still displayed real customer names, real email addresses, and real phone numbers to anyone who logged in as a test user. The masking tool did its job. It just never looked where the portal kept its data.
The Portal User Objects Masking Tools Skip
External users in Experience Cloud are still User records, but they carry fields a masking policy built for internal employees rarely touches. Username often contains a real email address. Email and Phone fields mirror the underlying Contact. FederationIdentifier and CommunityNickname can also expose identifiable strings tied to a real person.
Beyond the User object itself, several related tables carry PII that a narrow masking scope will miss entirely:
- NetworkMember - links external users to specific communities and can expose role and access patterns tied to a real identity
- LoginHistory and AuthSession - capture IP addresses, login timestamps, and device details for every portal authentication
- ContactPointAddress and ContactPointPhone - store delivery and contact details entered through self-service forms
- Custom objects built for portal registration, support intake, or partner onboarding - these are almost never on a masking vendor's default field list
None of these are exotic. They're standard parts of any Experience Cloud deployment. The problem is that masking rulesets get built once, against the objects everyone remembers, and then nobody revisits them when a new community goes live.
Guest Users: The Account Nobody Thinks to Mask
Every Experience Cloud site runs on a Guest User profile for anonymous visitors, and that account generates activity data even though no one logs into it directly. Form submissions, case creation through unauthenticated web-to-case, and anonymous chat sessions all route through the guest context before converting into real records tied to real people.
Here's where it gets messy. A prospect fills out a contact form on your public-facing community page. Salesforce creates a Lead or Case under the Guest User's runtime context, but the actual data in the record, name, email, message body, is entirely real. That record then gets copied into every sandbox refresh exactly like any other record, because nothing about its guest origin flags it for special masking treatment.
Admins tend to assume guest users don't hold PII because no human owns the account. The account doesn't. The records it creates absolutely do, and they need the same masking attention as anything entered by an authenticated employee.
Customer-Facing Content That Leaks Real Identities
Experience Cloud sites surface data back to the people who submitted it, which creates a second exposure path separate from backend database access. Case comments, Knowledge articles with customer-contributed answers, and Chatter-style community feeds all display names and sometimes contact details directly on screen.
A support rep testing a new case workflow in a sandbox will see the original customer's real name attached to a real complaint, often with order numbers, account details, or health and financial information embedded in free-text fields. Masking the backend Contact record doesn't fix this if the Case Comment or community post wasn't included in the same masking pass.
This is the pattern I keep coming back to with Experience Cloud: the PII doesn't live in one tidy place. It scatters across structured fields, free-text comments, and rendered community pages, and a masking policy that only targets structured fields on core objects will always leave something visible on screen.
A Masking Checklist for Experience Cloud Refreshes
Fixing this requires treating Experience Cloud as its own masking scope rather than an afterthought bolted onto a standard Salesforce masking run. Start with an inventory, because you cannot mask what you haven't identified.
| Area | What to Check |
|---|---|
| External User records | Username, Email, Phone, FederationIdentifier, CommunityNickname |
| Guest User activity | Cases, Leads, and custom records created through unauthenticated forms |
| Login and session data | LoginHistory, AuthSession, IP address fields tied to portal logins |
| Contact point objects | ContactPointAddress, ContactPointPhone linked to portal profiles |
| Rendered content | Case Comments, Knowledge articles, community feed posts with embedded names or contact details |
Run this inventory against every active site, not just the one everyone remembers. Organizations that have been on Experience Cloud for a few years often have two or three legacy communities still technically live, each with its own user base and its own untouched PII.
Once the inventory is built, map each item to a masking rule before the next sandbox refresh runs. MaskEzee applies this same logic by scanning community-related objects alongside standard Salesforce tables, so portal usernames, guest-submitted records, and contact point data get replaced with realistic fake equivalents in the same pass as everything else, rather than requiring a separate manual cleanup step.
Why This Belongs in GDPR Scope
Article 4 of GDPR defines personal data broadly enough that a portal username tied to a real email address counts, a logged IP address counts, and a case comment with a customer's name and complaint details counts twice over. None of this stops being personal data just because it originated from a self-service form instead of a sales rep's manual entry.
Regulators and auditors increasingly ask about test and development environments specifically, and an Experience Cloud sandbox with unmasked guest activity is a straightforward finding for anyone who knows where to look. It also widens the practical exposure, since community sandboxes are sometimes shared with implementation partners or external QA contractors who never should have seen real customer names in the first place.
Treat Experience Cloud as a full participant in your masking scope, not a bolt-on. The sites exist to let people outside your organization interact with your data directly, which makes the PII they generate at least as sensitive as anything in your core CRM tables, and in some cases more so.
Frequently Asked Questions
Does Salesforce data masking cover Experience Cloud sites automatically?
No. Most masking tools default to standard sales objects like Lead, Contact, and Account, and Experience Cloud data lives in separate places like NetworkMember, LoginHistory, and guest-submitted custom records. Admins need to explicitly add community-related objects to the masking scope or run a dedicated discovery pass to find them.
What PII does a Guest User account actually expose?
The Guest User account itself has no personal identity, but every record it creates through anonymous web forms, chat, or web-to-case does. Names, emails, phone numbers, and message content submitted through unauthenticated channels still contain real PII and get copied into sandboxes exactly like any other record.
Can masked Experience Cloud data still show real names in Case Comments or Chatter posts?
Yes, if the masking rule only targets structured fields on backend objects. Case Comments, Knowledge article contributions, and community feed posts often embed names and contact details in free-text fields that require their own masking pass, separate from the standard Contact or User record.
Are LoginHistory and session records considered personal data under GDPR?
Generally yes, since login timestamps and IP addresses can identify an individual, especially when tied to an external portal user account linked to a real name and email. These fields get copied into sandboxes during a refresh and should be included in any masking policy covering Experience Cloud.
How should admins handle legacy Experience Cloud sites that are no longer actively used?
Inactive or legacy sites still hold user records, login history, and submitted content from when they were active, and that data gets refreshed into sandboxes along with everything else. Include every site in the org, not just the current primary community, when building the masking inventory.