A sales rep calls the help desk because an approval request that should have routed to her regional manager just bounced back unassigned. Nothing in your org’s configuration changed this week. The validation rule that used to check the approver’s profile is now failing silently, because that field only shows each user their own profile now. Why can your Salesforce users only see their own profile name all of a sudden? This guide walks through where that breaks first, why it’s happening, and the two ways to fix it before it spreads further into your automation.
Quick Answer: This is expected behavior introduced in Salesforce’s Winter ’27 release, not a bug. Salesforce now restricts Profile Name visibility to users who hold the “View All Profiles” permission. Any validation rule, Flow, approval process, formula, report, or dashboard that referenced another user’s Profile Name by name can start failing, returning blank, or evaluating incorrectly the moment this rolls out to your instance. There are two fixes: (1) grant “View All Profiles” to the users or profiles that need the visibility back, or (2) refactor the affected automation so it stops depending on another user’s Profile Name at all. Most mid-sized orgs end up doing a mix of both, depending on how deeply Profile Name got baked into existing logic over the years.
1. Validation Rules That Reference Another User’s Profile Name
Validation rules break first because they’re the most common place admins hardcoded a profile check years ago and never revisited it. A rule comparing a field against another user’s Profile.Name now evaluates against a value that user can’t see, so the comparison silently returns false or blank instead of the name you expect. Consequently, records that should sail through get blocked, and records that should get blocked can slip through unnoticed depending on how the rule was written. This is annoying, but it’s correct behavior under the new permission model, not a system error.
Fix: Search Setup → Object Manager → Validation Rules for any formula referencing Profile.Name. Replace the name comparison with a check against ProfileId instead, which isn’t subject to the same visibility restriction. Test the rule by running it as a non-admin user in a full Sandbox copy before pushing to Production.
2. Flows and Approval Processes That Formula-Check Profile Name
Flows and approval processes fail for the same underlying reason, but the symptom looks different because the failure happens mid-transaction instead of at save time. An approval process entry criterion or a Flow formula resource that compares $User.Profile.Name against a hardcoded string stops matching, so approvals route to nobody or a Flow branch silently takes the wrong path. In practice, this is the failure mode that generates the most support tickets, because the person filing the ticket usually has no idea a permission change is the cause.
Fix: Open Flow Builder and search each affected Flow’s formula resources and decision elements for Profile Name references. Swap them for ProfileId comparisons, or better, a custom permission or permission set group check that doesn’t depend on profile visibility at all. For approval processes, rebuild the entry criteria the same way before reactivating.
3. Reports and Dashboards Grouped or Filtered by Profile Name
Reports and dashboards break more quietly, which makes them more dangerous. A report grouped or filtered by Profile Name shows a blank group for every user the report-runner can’t see the profile of, so totals undercount without throwing any visible error. Notably, this often goes unnoticed for weeks because the dashboard still loads and still looks plausible, just wrong.
Fix: Either grant “View All Profiles” to the users who run these reports regularly, or move the grouping/filter off Profile Name entirely and onto Role or a custom “Team” picklist field on the User object that isn’t subject to this restriction. The second option is more work up front but more stable long-term.
4. Custom Code and Formula Fields Reading User.Profile.Name
Custom code and formula fields are the least common break but the hardest to find, because they’re buried in Apex classes and formula field definitions rather than anywhere an admin would casually look. Apex referencing User.Profile.Name for a user other than the running user, or a formula field merging that value into an email template, now evaluates to null for everyone except the “View All Profiles” holders. As a result, merge fields render blank in customer-facing emails, and Apex logic branching on profile name string comparisons takes the wrong branch.
Fix: Search your codebase and formula field definitions for Profile.Name or ProfileName. Replace string comparisons with ProfileId equality checks, which are stable identifiers unaffected by this visibility change. Re-run existing Apex test classes as a non-admin user to confirm the fix actually holds.
This is exactly the kind of one-line release-note change that never shows up until something downstream breaks in production. It is the sort of thing we walk every automation in an org against before a seasonal release lands, because a permission change buried on page forty of the release notes can quietly touch validation rules, Flows, and reports that no single admin remembers building.
Frequently Asked Questions
Is this a Salesforce bug I should log a support case for?
No. This is documented, intended behavior tied to the Winter ’27 release’s Profile Name visibility change, not a defect. A support case will confirm the same thing the release notes already say. The fix is a configuration change on your end, either granting the permission or refactoring the automation that depends on it.
How do I find everywhere in my org this could break before it rolls out?
Search validation rule formulas, Flow formula resources, approval process entry criteria, report filters and groupings, and Apex or formula field definitions for any reference to Profile Name. Run that search in a full Sandbox copy first, logged in as a non-admin user, since admins typically retain broader visibility by default. Anything that behaves differently between your admin login and a standard user login is a candidate.
Does granting “View All Profiles” create a security risk?
Profile names are lower-sensitivity data than most fields Salesforce restricts, so the risk is modest for most orgs. Smaller organizations often grant it broadly and move on without issue. Larger organizations with many custom profiles sometimes prefer the refactor path instead, specifically to avoid a blanket visibility grant they’d have to explain later in a security review.
When does this actually take effect in my org?
Winter ’27 enforcement began rolling out in September 2026, with Sandboxes typically receiving the release ahead of Production. Check your Sandbox’s release version under Setup to see whether you’re already on Winter ’27. If you are, and you haven’t audited for this yet, treat it as already live rather than upcoming.
How do I get started fixing this across a large, established org?
Start with an inventory pass across validation rules, Flows, approval processes, reports, and code before touching anything, since fixing issues one support ticket at a time means you’re always one step behind the next broken process. A Salesforce consulting engagement or org review can run that inventory in a few hours using metadata search rather than manual clicking through every automation by hand.
Not Sure What Else in the Winter ’27 Release Is About to Break?
Book a free 90-minute Salesforce Org Review with the Cloud Nexus team. We’ll walk your validation rules, Flows, approval processes, and reports for every reference to Profile Name and other Winter ’27 changes, flag what’s already broken versus what’s about to be, and hand you a fix list ranked by how many processes each item touches.
Book Your Free Org Review →
