Salesforce profile filtering in Winter ’27: test who still needs profile visibility

Salesforce is enforcing Profile Filtering with Winter ’27. When the setting is active, users generally stop seeing the names of profiles other than their own unless they have the new View All Profiles permission or an existing administrative permission that provides equivalent visibility.

This is a sensible need-to-know control, not a redesign of Salesforce’s whole access model. It does not itself remove object permissions, record access or the ability to perform every delegated task. It does, however, change what profile metadata a user or process can see, and some work depends on that visibility more than its owner may realise.

With the remaining Winter ’27 production upgrade weekends scheduled for 2 and 9 October 2026, platform owners should verify their own instance date and test the update now. The aim is not to restore broad visibility automatically. It is to identify the small group of legitimate tasks that require profile names and grant the narrowest appropriate access.

What Salesforce has confirmed

Salesforce says Profile Filtering was first available in Summer ’26 and is enforced in Winter ’27. The update applies across Lightning Experience and Salesforce Classic in Essentials, Professional, Enterprise, Performance, Unlimited, Developer and Database.com editions.

Salesforce’s release calendar lists Winter ’27 production upgrades on 4 September, 2 October and 9 October 2026. Some organisations are therefore already on the release while others are approaching enforcement. The authoritative date for a particular org is its instance maintenance entry in Salesforce Trust.

With Profile Filtering enabled, a user normally sees their own profile name. Wider visibility is available through View All Profiles. Salesforce also documents several broader permissions whose holders can already see all profiles, including Customize Application, Manage Users, Manage Profiles and Permission Sets, Create and Set Up Experiences, Manage Customer Users, Manage External Users and Delegated External User Administrator.

Those are confirmed platform facts. The testing priorities and governance method below are Ostrelis recommendations based on the operational dependencies Salesforce documents.

Why profile names are sensitive metadata

A profile name can reveal how an organisation structures administrators, contractors, service teams, executives or external users. Hiding names that a person does not need reduces unnecessary knowledge about the access model. It also moves Salesforce towards a clearer least-privilege position: profile visibility becomes something justified by a role, rather than background metadata visible by default.

The control has limits. Salesforce documents situations in which profile names can still appear to users performing specific authorised work, such as reviewing Setup Audit Trail, creating tabs or record types through certain wizards, or administering delegated groups. Profile Filtering should therefore be understood as a reduction in general visibility, not a promise that every profile reference disappears from every administrative surface.

Which activities deserve testing

Start with people and processes that inspect or select profiles without being full administrators. Delegated administrators, Experience Cloud support teams, identity specialists, reporting analysts and operations staff are more likely to encounter a changed lookup, list or record than ordinary business users.

Login-flow administration needs explicit attention. Salesforce states that, with Profile Filtering enabled, users cannot create or edit login flows unless they have View All Profiles. If a team delegates login-flow maintenance, test the complete create, edit and activation process using the delegated user—not a System Administrator.

Records and automation that reference profile names can also behave differently. Salesforce’s troubleshooting guidance warns that users without View All Profiles can be unable to load records containing fields that reference profile names. That makes custom objects, managed packages, flows, screens and reports containing Profile lookups or derived profile data useful search targets.

CRM Analytics has a documented dependency. Salesforce advises granting View All Profiles to the Analytics Cloud Integration User when Profile Filtering is enabled if the Profile object must be synchronised. Do not infer from this that every integration user needs the permission. Confirm whether a process actually reads Profile metadata and follow the product-specific guidance for that integration.

Industry and managed-package features may have their own requirements. A package that displays profile choices or enrols users can fail even if its core business-object access remains correct. Check supplier documentation and test supported workflows before changing a managed component or granting broad permissions.

Do not treat View All Profiles as harmless

View All Profiles is narrower than permissions such as Manage Users, and that makes it a better option when visibility is the genuine requirement. It is still additional access. Assigning it to every user who raises a ticket would undo the purpose of the update and make later access reviews harder to defend.

For each proposed assignment, record the task, affected environment, expected duration, owner and evidence that the task fails without wider visibility. Prefer a permission set or governed permission-set group over adding another entitlement directly to a heavily reused profile. Where access is temporary, use the organisation’s normal expiry and review process.

Also avoid granting a broader administrative permission merely because it happens to include profile visibility. If a delegated operator only needs to see profile names, Customize Application or Manage Users would normally be a disproportionate remedy.

A practical Winter ’27 test plan

1. Confirm the instance window. Check Salesforce Trust rather than assuming that every production org upgrades on the same weekend.
2. Review the release update. In Setup, open Release Updates and follow Salesforce’s testing and activation steps for Enable Profile Filtering.
3. Build a candidate list. Identify delegated administrators, login-flow owners, Experience Cloud operators, analytics integration users, packages and custom processes that read or display profile data.
4. Search for profile dependencies. Review custom-object fields, Flow resources, reports, Apex, middleware mappings and analytics recipes that reference Profile or profile names.
5. Test with representative identities. Use the actual permission shape of each affected role. An administrator test cannot prove what a restricted user will see.
6. Check negative cases. Confirm that people without a business need can no longer browse unrelated profile names and that errors do not expose restricted metadata.
7. Grant narrowly and retest. Where a task genuinely requires visibility, assign View All Profiles through a controlled permission set and prove the full business outcome.
8. Monitor after upgrade. Watch analytics jobs, support cases, login-flow work and integration errors, with a named owner for triage.

What a good evidence record looks like

A short control record is more valuable than a long generic checklist. Capture the org and instance, release date, update status, test user, tested task, expected result, actual result, permission decision and approver. For integrations, include the running user, objects queried and a successful post-change job or data reconciliation.

Keep a separate list of unresolved supplier dependencies. If a vendor cannot yet confirm support, record the version, case reference, operational impact and next decision date. Silence should not be interpreted as compatibility.

The Ostrelis view

Profile Filtering is a modest control with a useful governance lesson. Metadata access can be operationally important even when it does not grant direct access to customer records. Platform teams should understand who relies on that metadata, then preserve only the access that has a defensible purpose.

The right outcome is not zero support tickets at any cost. It is a tested production change, a small and reviewable set of View All Profiles assignments, and clear evidence for every exception. That keeps delegated administration and integrations working without restoring the broad visibility Salesforce is deliberately narrowing.

Ostrelis can help organisations assess release updates, trace permission dependencies, test delegated administration and manage access changes through controlled releases. See our Salesforce managed services, platform health checks and approach and experience. Need help getting prepared? Talk to a Salesforce expert.