November 6, 2026

Salesforce Spring '27 Conceals PII from Guest Users: Why Enforcement Changes Nothing Until You Edit the Field Set

Spring '27 gives guest users their own PII field set. In existing orgs it starts as a copy, so nothing changes until you edit it. What to add, and what breaks.

TL;DR

The Conceal Personal Information Fields from Guest Users release update was first available in Winter '27 and is enforced in Spring '27. It turns on a setting called Independent Guest Field Masking.
Once it is on, guest users (unauthenticated visitors to your Aura, LWR or Visualforce sites) are masked by a new field set, Guest_PersonalInfo_EPIM. Logged-in portal users stay on the existing PersonalInfo_EPIM field set.
In an existing org, the new field set starts as a copy of the old one. Guests see exactly what they saw yesterday. Enforcement on its own protects nothing extra; the protection is whatever you add.
Orgs created in Winter '27 or later start much stricter: 59 standard fields plus every custom User field masked from guests. Masked lookups such as UserRole return null with no error, so guest pages can break quietly.
You cannot switch Independent Guest Field Masking off after enabling it. Decide on the field list in a sandbox first.

What You'll Learn

What the release update actually changes, and who it applies to
Why an existing org sees no difference on enforcement day, and why that is the risk
Which fields are worth adding to the guest field set, and which ones break things when you do
How to find code and Flows that read User fields on guest pages before they start returning blanks
How to test it, given that the switch is one-way

The Problem

Salesforce has hidden personal information on User records from external users since Enhanced Personal Information Management (EPIM) became mandatory in Spring '23. One field set, PersonalInfo_EPIM, decides which User fields external users cannot see, and out of the box it covers 30 fields.

The trouble is that "external users" lumps together two very different audiences. A logged-in partner on your portal usually needs to see a fair amount about the internal users they work with. An anonymous visitor to a public help centre needs to see almost nothing. With one shared field set, every field you hid from guests was also hidden from partners, so most orgs settled on a list that suited the portal and left guests with more than they needed.

Spring '27 fixes that by giving guests their own field set. What most release summaries leave out is that, for an org that already exists, Salesforce builds the new guest field set as a copy of your current one. That is a sensible default, because it guarantees nothing breaks. It also means the release update gets marked as enforced, the item disappears from your Release Updates list, and your guest exposure is exactly what it was before.

Common questions this article answers:

Does the Spring '27 guest PII update change what guests can see in my org?
Which User fields should I hide from guests that I am not hiding today?
Why would a field on a guest page start showing as blank after this?
Can I undo it if something breaks?

Quick Answer

The Conceal Personal Information Fields from Guest Users release update, enforced in Spring '27, turns on Independent Guest Field Masking. After that, the Guest_PersonalInfo_EPIM field set controls which User fields guests can see, and PersonalInfo_EPIM controls portal users only. It applies to Aura, LWR and Visualforce sites in Enterprise, Performance, Unlimited and Developer editions, and it requires EPIM and Digital Experiences to be enabled. In existing orgs the guest field set starts as a copy of PersonalInfo_EPIM, so nothing changes until you add fields to it in Object Manager, under User, Field Sets, Guest_PersonalInfo_EPIM. Good candidates are login and password dates, locale and preference fields, and lookups such as Account, Contact, Profile and UserRole, all of which Salesforce masks by default in new orgs. Before adding any of them, check whether guest-facing Apex, Flows or components read those fields, because a masked field returns null with no error. The setting cannot be disabled once enabled, so test in a sandbox first.

What the release update changes

There are two field sets on the User object after this update, and each has one job:

Field set	Applies to	Starting contents in an existing org
PersonalInfo_EPIM	Authenticated external users (portal users)	Unchanged
Guest_PersonalInfo_EPIM	Unauthenticated external users (guest users)	A copy of your PersonalInfo_EPIM

Salesforce's release note puts the reasoning plainly: guest users typically need fewer User fields than portal users, so a dedicated guest field set lets you hide more from guests without changing what portal users see.

A few details from the configuration article are worth knowing before you touch it:

It is one-way. "You can't disable this setting after you enable it." EPIM must stay enabled too.
Prerequisites. EPIM and Digital Experiences both have to be on. Every org has had EPIM since Spring '23, so in practice this means any org with Experience Cloud.
What you can add. Any standard or custom User field except system fields, formula fields, the Default Currency ISO Code field and the Information Currency field.
Where the switch lives. Setup, then User Management Settings, then Independent Guest Field Masking. You can turn it on today; the release update only forces it in Spring '27.

Why existing orgs and new orgs end up in different places

In an existing org, enabling the setting copies your current PersonalInfo_EPIM into Guest_PersonalInfo_EPIM. If you never customised PersonalInfo_EPIM, that is the 30 default fields. Guest visibility is preserved exactly.

In a new org created in Winter '27 or later, if Digital Experiences and EPIM are enabled, Independent Guest Field Masking is already on, and the guest field set starts with what Salesforce calls an expanded default: 59 standard fields plus all custom fields on the User object.

So two orgs on the same release, running the same site code, can mask very different things from guests. If you build or demo guest-facing features in a Developer Edition org created since Winter '27 with Digital Experiences on, it is masking far more than your production org is. A component that works in production can show blanks there, and the reverse is the more dangerous case: something tested only against production defaults can break the day you tighten production to match.

What to add to the guest field set

Salesforce's own expanded default for new orgs is the best starting list, because it is what Salesforce considers safe to hide from guests. On top of the original 30, it masks these groups:

Group	Fields
Login and password	LastLoginDate, LastLoginMessageDate, LastPasswordChangeDate, PasswordExpirationDate, NumberOfFailedLogins, HasUserVerifiedEmail, HasUserVerifiedPhone, SuAccessExpirationDate
Lookups	Account, Contact, DelegatedApprover, Individual, Person, Profile, UserRole, CallCenter, Workspace
Banner and photo	BannerPhoto, BannerPhotoUrl, FullPhotoUrl, MediumBannerPhotoUrl, MediumPhotoUrl, SmallBannerPhotoUrl, SmallPhotoUrl, ProfilePhoto, IsProfilePhotoActive
Locale and preferences	EmailEncodingKey, LanguageLocaleKey, LocaleSidKey, TimeZoneSidKey, DigestFrequency, DefaultGroupNotificationFrequency, DefaultDivision, ForecastEnabled, ReceivesAdminInfoEmails, ReceivesInfoEmails, OutOfOfficeMessage, StartDay, EndDay, SharingType, UserSubtype, IsExtIndicatorVisible, IsSystemControlled
Names	MiddleName, Suffix
Other	LastDashboard, LastPricebook, LastReferencedDate, LastTabSet, LastViewedDate, RawCurrentStatus, ChatterAdoptionStage, ChatterAdoptionStageModifiedDate, OfflinePdaTrialExpirationDate, OfflineTrialExpirationDate, WirelessEmail, StayInTouchNote, StayInTouchSignature, StayInTouchSubject
Custom	Every custom field on User

If I had to pick where to start, it would be the login group and the lookups. Login and password dates tell an anonymous visitor which accounts are active, which are stale, and when credentials were last rotated. That is reconnaissance data with no legitimate use on a public page. The lookups matter because they are how an anonymous visitor walks from a user to their Account, Contact, Profile and role, which describes the shape of your organisation.

Custom User fields deserve a look on their own. Orgs put all sorts of things on User over the years, from employee IDs to cost centres to phone extensions, and none of it was designed with a public audience in mind.

What breaks when you add fields

The configuration article is direct about the failure mode, and it is why you should test rather than copy the whole list across.

Masked fields return null, with no error. When an Apex class, Flow or component runs as the guest user and reads a masked field, it gets a null. That includes relationship traversal: Salesforce's own example is user.UserRole.Name, which comes back null for a guest once UserRole is masked. Nothing throws. The page renders with a gap, or a Flow decision takes the wrong branch.

Photos disappear. If your site shows a case owner's or an article author's avatar to guests, it reads the photo URL fields. Mask them and the avatars go.

The symptom looks like a sharing problem. Salesforce's troubleshooting tip is worth remembering: if a guest sees a blank User field you know has data, and field-level security is set correctly, EPIM is probably masking it. The fix is to remove that field from Guest_PersonalInfo_EPIM, not to widen FLS or sharing.

To find exposure before you change anything, search the code and metadata that runs on your guest pages for User relationship reads. From the root of your Salesforce DX project:

# Apex, LWC and Aura reading User fields through common relationships
grep -rnE "(Owner|CreatedBy|LastModifiedBy|User)\.(UserRole|Profile|Account|Contact|Manager|SmallPhotoUrl|MediumPhotoUrl|FullPhotoUrl|BannerPhotoUrl|LastLoginDate|TimeZoneSidKey|LanguageLocaleKey)" \
  force-app/ --include="*.cls" --include="*.js" --include="*.html" --include="*.cmp"

# Flows that reference User fields (review any that run on guest-facing pages)
grep -rlE "Owner:User\.|<objectType>User</objectType>" force-app/ --include="*.flow-meta.xml"

Neither search tells you whether the code runs as a guest. That is still a judgement call: anything behind a page or component on a public site page, a screen Flow exposed to guests, or an Apex controller called from a guest-accessible component is in scope. Make that short list, then check each item against the fields you plan to mask.

A safe order to do it in

Because you cannot turn the setting off again, the sandbox is where you make your decisions:

Refresh a sandbox from production so its PersonalInfo_EPIM matches what production has today.
Enable Independent Guest Field Masking in the sandbox, from Setup, then User Management Settings. Confirm Guest_PersonalInfo_EPIM appeared under Object Manager, User, Field Sets, and that it matches PersonalInfo_EPIM.
Run the searches above and list the guest-facing code and Flows that read User fields.
Add fields in small groups. Start with the login group, then the custom fields you are sure are internal only, then the lookups.
Test as a guest after each group. Open the site in a private browser window and walk every public page, especially ones showing owners, authors or assignees. Salesforce's Test Guest User Access article covers the options.
Write down what you deliberately left visible and why. If a public component really needs SmallPhotoUrl, that is a fine decision, but it should be a recorded one.
Repeat in production on a quiet morning, with the field list you settled on.

If you do nothing, Salesforce enables the setting for you in Spring '27, and because existing orgs get the copy, nothing visible happens. The one-way switch gets flipped and the work it exists to enable never happens, which is the outcome to avoid.

What your users will see

Portal users see no change at all; their field set is untouched. Guests should see slightly less on pages that show internal people. If your public site shows staff names and photos deliberately, for example a team directory, tell the site owner before you mask photos so the change does not arrive as a bug report.

Frequently Asked Questions

Q: Does enforcement in Spring '27 change what guests see in my existing org?

A: No. When the setting turns on in an existing org, Guest_PersonalInfo_EPIM is created as a copy of your PersonalInfo_EPIM, so guest visibility is preserved. The extra protection only exists once you add fields to the guest field set.

Q: Can I turn Independent Guest Field Masking off if something breaks?

A: No. Salesforce states that you can't disable the setting once enabled. What you can do is remove fields from Guest_PersonalInfo_EPIM, which restores their visibility to guests. That is the rollback path, which is why adding fields in small groups makes sense.

Q: Does this affect logged-in community or partner users?

A: No. Authenticated external users stay on the PersonalInfo_EPIM field set, which this update does not change. That separation is the whole point of the update.

Q: Why is a User field blank on my guest page when FLS allows it?

A: Almost certainly EPIM masking. Salesforce's own guidance is that a blank User field with correct field-level security usually means the field is in the masking field set. Remove it from Guest_PersonalInfo_EPIM if guests genuinely need it.

Q: Does this protect Contact, Case or custom object data from guests?

A: No. EPIM only covers fields on the User object. Guest access to other objects is still controlled by the guest profile's object and field permissions and by guest sharing rules. The guest user checklist post walks through verifying those.

Key Takeaways

Spring '27 enforces a split, not a lockdown. Guests get their own field set, Guest_PersonalInfo_EPIM, separate from portal users.
Existing orgs get a copy, so nothing changes on enforcement day. The protection is the fields you add afterwards.
New orgs start far stricter, with 59 standard fields and all custom User fields masked, so recently created orgs and production can behave differently.
Masked fields return null without an error, including relationship reads like UserRole.Name, so test guest pages rather than trusting the absence of errors.
The switch is one-way. Decide the field list in a sandbox and roll back by removing fields, not by disabling the setting.

What's Next?

Recommended Reading:

Action Items:

Check Setup, Release Updates for Conceal Personal Information Fields from Guest Users, and note whether Independent Guest Field Masking is already on in each of your orgs.
Run the code and Flow searches against your project and list the guest-facing items that read User fields.
In a fresh sandbox, enable the setting, add the login group and internal custom fields to Guest_PersonalInfo_EPIM, and test every public page as a guest before doing the same in production.

Resources & References

Written by the team at CloudCounsel — builders of Paywren and Mehfil.

Responses

Checking your session.

Loading responses.