TL;DR
- Winter '27 enforces the Enable Profile Filtering release update. Once it lands, an ordinary user can see only their own profile name. Every other profile in the org becomes invisible to them.
- Eight permissions bypass the filter, including View All Profiles, Manage Users, and Customize Application. Most admins already hold at least one, which is why this is easy to miss during testing.
- The breakage is not in formulas that read the running user's own profile. It is in automation and code that reads somebody else's profile name, such as a record owner's or an approver's.
- One documented side effect catches people out: with Profile Filtering on, users cannot create or edit login flows unless they have View All Profiles.
- You do not have to wait for the release. The toggle already exists in Setup under User Management Settings, so you can switch it on in a sandbox now and find your problems on your own schedule.
What You'll Learn
- What Profile Filtering changes, in terms of who can see what
- Which eight permissions bypass it, and why that makes admin testing misleading
- How to tell the difference between automation that breaks and automation that is fine
- How to dry-run the change in a sandbox before your org reaches Winter '27
- What to tell your users, and why granting View All Profiles to silence the errors is the wrong fix
The Problem
Profile names leak more than people expect. In a default org, any user can see the full list of profile names, which means they can see that you have a "Finance Approver Elevated" profile, a "Contractor Read Only" profile, and a profile named after the acquisition you have not announced yet. None of that is data in the record sense, but it is a map of how your org is structured and where the privileged access lives, handed to anyone with a login.
Salesforce is closing that off. Profile Filtering restricts profile visibility to the users whose job needs it, and Winter '27 makes it the default rather than an option you opt into.
The catch is that org configuration has been reading profile names freely for years, because it could. Validation rules, Flows, approval processes, and Apex all reference profiles, and some of that logic reads the profile of a user who is not the person running the transaction. That is the part which can change behaviour, and it changes quietly, because nothing throws a banner saying "this ran differently because of Profile Filtering".
Common questions this article answers:
- What exactly can users no longer see once Profile Filtering is on?
- Which of my Flows, validation rules, and Apex classes are actually at risk?
- How do I test this before the release forces it on me?
Quick Answer
Winter '27 enforces the Enable Profile Filtering release update. After enforcement, users see only their own profile name unless they hold one of eight permissions: View All Profiles, Customize Application, Manage Users, Manage Profiles and Permission Sets, Create and Set Up Experiences, Manage Customer Users, Manage External Users, or Delegated External User Administrator. Logic that reads the running user's own profile, such as a validation rule using $Profile.Name, is unaffected, because a user can always see their own profile. What needs testing is anything that reads a different user's profile name, such as a Flow that looks up a record owner's profile or an approval step that routes on the approver's profile. There is also a documented restriction: with Profile Filtering enabled, users cannot create or edit login flows without View All Profiles. Test it early by enabling the toggle in a sandbox from Setup, then User Management Settings, then Profile Filtering. Resist fixing failures by handing out View All Profiles, because that gives back exactly the visibility the update is removing.
What Profile Filtering actually changes
Profile Filtering is a single org setting with a narrow job: it controls whether a user can see profile names other than their own.
With it off, which is how most existing orgs run today, every user sees every profile name wherever profile names appear. With it on, a user sees their own profile and nothing else, unless they hold a permission that grants the wider view.
That is the whole change. It does not alter what a profile grants, it does not change record access, and it does not touch permission set assignment. It changes visibility of the profile list, which sounds cosmetic until you remember how much configuration reads that list.
Salesforce's own documentation is candid that the filter is not absolute. Profile names still surface in places where a privileged action inherently exposes them, such as the Setup Audit Trail, creating tabs and record types, configuring delegated administration, and administering external user groups. Those all sit behind permissions that already bypass the filter, so the exceptions are consistent rather than leaky, but it is worth knowing that "filtered" means filtered for ordinary users rather than erased everywhere.
The eight permissions that bypass it
A user sees all profile names if they have any one of these:
| Permission | Typically held by |
|---|---|
| View All Profiles | Anyone explicitly granted the wider view |
| Customize Application | Admins, and a lot of power users who should not have it |
| Manage Users | Admins and user-admin delegates |
| Manage Profiles and Permission Sets | Admins and release managers |
| Create and Set Up Experiences | Experience Cloud admins |
| Manage Customer Users | Community and partner user admins |
| Manage External Users | Partner and channel admins |
| Delegated External User Administrator | Delegated partner admins |
Worth knowing where those two facts come from, because they read differently. The release update itself says only that profile filtering "prevents users from viewing profile names other than their own unless they're assigned the View All Profiles permission", and tells you to assign that permission to anyone whose role needs the wider view. The eight-permission list above comes from the Profile Filtering feature documentation, which describes the full set that confers visibility. Both are correct: View All Profiles is the permission you deliberately grant, and the other seven confer the same visibility as a side effect of something else they do.
Read that list again with your own login in mind. If you are the person testing this change, you almost certainly hold Customize Application or Manage Users, which means you will not experience the filter at all. You can enable Profile Filtering, click around happily, and conclude that nothing broke, while a standard user hits the same screens and sees something different.
This is the single most common way teams get a false pass on this update. Test as a standard user, using login-as or a real test account with a representative profile, not as yourself.
It is also a good moment to notice how widely Customize Application is granted in most orgs. It is a heavy permission that many people hold for one narrow reason, and it silently confers profile visibility along with a great deal else. If that sounds familiar, the same argument applies to the permissions developers accumulate, which we cover in What Developers Actually Need Instead of Modify All Data.
Where this breaks, and where it does not
The useful distinction is whose profile the logic reads.
Reading your own profile is fine. A validation rule with $Profile.Name = "System Administrator", a Flow decision on $Profile.Id, or a formula that branches on the running user's profile all keep working. A user can always see their own profile, so the filter never gets in the way. This covers a large share of real-world profile references, which is why the update is less catastrophic than the summaries suggest.
Reading someone else's profile is where you look. These are the patterns worth listing out of your org:
- A Flow that looks up the record owner and reads
Owner.Profile.Nameto decide routing or visibility - A validation rule that references a related user's profile rather than the running user's, for example on a record's Owner or a custom User lookup
- An approval process whose step logic or entry criteria evaluates the assigned approver's profile
- Apex that queries
SELECT Profile.Name FROM User WHERE Id = :someOtherUserId, particularly in classes now running in user mode - Lightning components and screen Flows that display a list of users with their profile names to an end user
That last category is the one users will notice first, because it is visible. A column of profile names in a custom user picker simply stops being populated for people without the bypass permissions.
Be aware that the exact behaviour of the code cases depends on execution context. Apex running in system mode does not enforce the same visibility as Apex running in user mode, and Salesforce has been moving Apex toward user mode by default, which is a separate change we cover in the Summer '26 secure-by-default post. The practical consequence is that you cannot reason your way to a complete list from the code alone. You need to run it.
To build your starting inventory, pull the metadata and search it rather than clicking through Setup. If you already keep your org's metadata in git, this is a grep:
# Retrieve the metadata types most likely to reference profiles
sf project retrieve start \
--metadata Flow ValidationRule ApexClass ApprovalProcess \
--target-org myorg
# Then search the retrieved source for cross-user profile references
grep -rn "Profile\.Name\|Profile\.Id\|Owner\.Profile" force-app/
Filter the results down to the ones that reference a user other than the running user. Those are your test cases. If you do not yet keep security metadata in version control, Fetch security metadata with the sf CLI covers the retrieve side.
The login flows restriction
One consequence is documented plainly by Salesforce and deserves its own mention, because it looks like a bug when you meet it cold: with Profile Filtering enabled, users cannot create or edit login flows. The login flow builder needs to associate a flow with profiles, and it cannot do that without profile visibility.
If someone on your team maintains login flows and is not a full admin, they will need View All Profiles specifically. This is the one case where granting the permission is the intended answer rather than a workaround, because the task genuinely requires seeing the profile list.
Testing it before the release does it for you
Salesforce states that the update is available starting in Summer '26, so the setting is already in your org today. That makes this one of the more testable release updates in the wave.
- Pick a sandbox that resembles production. A full or partial copy sandbox with real automation and a realistic user mix. A developer sandbox with three users will not surface anything.
- Enable the toggle. In Setup, go to User Management Settings and switch on Profile Filtering.
- Test as a standard user, not as yourself. Use login-as, or a dedicated test user on a normal business profile. This is the step that decides whether the exercise is worth anything.
- Exercise the list you built from metadata. Run each Flow, save records against each validation rule, walk an approval through its steps, and open any screen that shows other users' profile names.
- Watch for silence, not just errors. The failure mode here is usually a blank value or a decision branching the wrong way, not a red error message. Check outcomes, not just whether the transaction saved.
- Fix by refactoring, not by granting. Where logic depends on another user's profile, move it onto something designed for the job: a permission set assignment check, a custom field on the User record, or a role. Profiles were never a good way to model this, and this update is a reasonable prompt to stop.
- Turn the toggle off again if you need the sandbox for other work, then leave it on permanently once you are clean.
The refactoring point in step 6 is the one with lasting value. Logic that branches on profile name is brittle for reasons that have nothing to do with this release: profile names get renamed, orgs consolidate profiles, and a string comparison against "System Administrator" breaks the moment somebody clones it. Permission sets model capability directly, and moving this logic across is work you would benefit from regardless. We make that case at length in Deployable permission sets for delivery teams.
What your users will see
Most users will see nothing at all, which is the intended outcome. For the ones who do notice, here is the substance to put in a comms email:
From our Winter '27 update, Salesforce is changing how profile information is displayed. A profile is the label that describes your access level in Salesforce. Previously everyone could see the full list of profile names used across the organisation. From this release, you will see only your own.
If you use a screen or report that used to display other people's profile names, that column may now be blank. This is expected, and it is a security improvement rather than a fault. If a screen you rely on for your job no longer shows information you need, please raise it with the Salesforce team rather than working around it, and we will look at whether that screen should be using a different field.
Nothing about your own access is changing. You can still do everything you could do before.
Two things make that message work. It explains what a profile is, because most users have never needed the word. And it tells people what to do when something looks wrong, which heads off the workaround culture where somebody quietly builds a spreadsheet instead of reporting the gap.
Frequently Asked Questions
Q: Will Profile Filtering change anyone's actual access?
A: No. It changes visibility of profile names only. Nobody gains or loses a permission, record access, or field access because of this update. The confusion arises because logic that reads profile names can behave differently, which can look like an access change to an end user when it is really a configuration change.
Q: Can I just grant View All Profiles to everyone and move on?
A: You can, and it will make the symptoms disappear, but it undoes the entire point of the update and leaves you with the original exposure. Salesforce positions View All Profiles as the fallback for cases that genuinely need the wider view, such as maintaining login flows. If you find yourself granting it broadly, that is a signal your automation is reading profiles where it should be reading permission sets or roles.
Q: My validation rules use $Profile.Name. Do I need to change them?
A: Almost certainly not. $Profile.Name resolves to the running user's own profile, and a user can always see their own. The rules to check are the ones referencing a different user's profile, such as a record owner's or an approver's, which is a much smaller set.
Q: Why did my admin testing show no problems?
A: Because you almost certainly hold Customize Application, Manage Users, or Manage Profiles and Permission Sets, any of which bypasses the filter entirely. Admins do not experience this change. Test with login-as against a standard business profile instead.
Q: When exactly does this hit my org?
A: It enforces with your org's Winter '27 upgrade, and Salesforce rolls major releases out by instance rather than on one global date. Salesforce Trust lists five major release dates: 29 August, 5 September, 3 October, 9 October and 10 October 2026. Find your instance on Trust to get your date, and check Setup then Release Updates for the enforcement date shown for your org.
Key Takeaways
- Profile Filtering hides other users' profile names, and Winter '27 makes it the default rather than an option.
- Eight permissions bypass it, and admins hold most of them, so testing as yourself will show you a false pass. Test with login-as as a standard user.
- Logic reading the running user's own profile is safe. Logic reading another user's profile is what needs testing, and it usually fails silently rather than loudly.
- Login flows need View All Profiles once Profile Filtering is on. This is the one case where granting the permission is the correct answer.
- Refactor to permission sets rather than granting View All Profiles, because profile-name string comparisons were fragile long before this release update existed.
What's Next?
Recommended Reading:
- Salesforce Winter '27 Security Readiness: The Five Release Updates and the Sandbox Window to Test Them
- Salesforce Security Enforcement in 2026: Every Change, Date, and What Admins Must Do
- What Developers Actually Need Instead of Modify All Data
- Deployable permission sets for delivery teams
Action Items:
- Retrieve Flow, ValidationRule, ApexClass, and ApprovalProcess metadata and grep it for cross-user profile references to build your test list.
- Enable Profile Filtering in a representative sandbox and walk that list as a standard user via login-as, checking outcomes rather than just errors.
- Refactor what breaks onto permission sets or roles, and grant View All Profiles only to people who maintain login flows.
Resources & References
- Limit Profile Details to Required Users (Salesforce Help)
- Release Updates, including the "Scheduled to Be Enforced in Winter '27" list (Salesforce Help)
- Salesforce Trust Status (find your instance's release date)
- Salesforce Winter '27 Release: What to Expect and How to Prepare (Salesforce Ben)
- Fetch security metadata with the sf CLI