Winter '27 Is About to Change Who Can See What in Salesforce

Salesforce's Winter '27 Release Updates enforce this release cycle. The exact date depends on your instance's major-release upgrade window (check Trust Status for yours). Most of what's on the list is routine: accessibility tweaks, an email-verification setting, a tax-calculation fix. Two items aren't routine, at least not for anyone who cares about access governance. They change who is allowed to see or touch something that, until now, was governed more loosely.

Neither one is a new feature announcement. Both are the kind of change that breaks something quietly on enforcement day if nobody checked first.

Change one: Profile Names stop being visible by default

Right now, most users in most orgs can see other people's Profile Names, even without being granted the View All Profiles permission. It's just been open by default. Winter '27 closes that: going forward, a user can only see their own Profile Name unless View All Profiles is explicitly granted.

That sounds narrow until you consider where a Profile Name reference can live. Salesforce's own release note doesn't spell this out in detail, but SalesforceBen's prep guide breaks down the likely places: validation rules, flows, assignment rules, approval processes, sharing rules, Apex, Lightning Web Components, reports, list views, dashboards, custom metadata, formula fields. Anything built to check or display someone else's profile (a flow that branches based on the record owner's profile, for instance) stops seeing what it expects unless the running user has View All Profiles.

Change two: a narrower permission for Transaction Security Policies

Salesforce also introduced a dedicated Modify Transaction Security Policy permission. Before this, having Customize Application was enough to create, edit, or delete a Transaction Security Policy. Under the new model, Customize Application on its own drops to view-only. Actually modifying a policy requires the new permission specifically. (This applies to orgs with Event Monitoring or Salesforce Shield; check both against your edition and licenses before assuming it affects you.)

Different mechanism, same shape as the first change: a capability that used to ride along with a broad permission now needs a specific one.

The actual question this raises

Salesforce's own release notes already answer "what does Winter '27 do" in full, with sandbox and production steps for each update, and SalesforceBen's prep guide covers the how-to well. The more useful question before enforcement day is which of your permission sets and profiles currently grant View All Profiles, Customize Application, or the new Modify Transaction Security Policy permission, and whether whoever's holding them expected that.

That's not a question Setup answers quickly. Checking one permission set means opening it, scrolling to the right section, and reading down a long list of system permissions to see which are checked. Multiply that by however many permission sets and profiles a typical org accumulates, and it's an afternoon, not a five-minute check.

Permission Sets Reporting Helper, part of Power User Toolkit, exists for exactly that read: open a permission set, and its User Permissions section shows every system-level permission that's actually checked (View All Profiles, Customize Application, and the rest) in one accordion instead of a page you scroll and squint at. It doesn't scan your whole org and hand back "everyone with View All Profiles" in one shot. It's a fast per-permission-set read, which is what makes going through your candidate list of permission sets, the ones tied to admin-adjacent or reporting-heavy roles, actually fast instead of tedious.

Where to go from here

If a permission set turns out to already grant one of these, that's not automatically a problem. It might be exactly the access that role needs. The point is knowing before Salesforce's enforcement date, not after something breaks in production and someone's asking why.

Next week: what to actually do with that list once you've pulled it, which permission sets are worth flagging, and how this connects to the recurring access-review cadence covered in What a Real Salesforce Access Review Requires.

For the full breakdown of what Permission Sets Reporting Helper shows, see A Faster Salesforce Permission Set Audit. Or start at the Power User Toolkit overview.

Get Power User Toolkit on Salesforce AppExchange →