How To Clean Up Permission Sets

Winter '27 just changed how profile visibility works, and that is a good excuse to finally look at who can see what.

A Salesforce permission set audit starts by pulling every permission set in the org next to a current list of job roles, then checking three things for each one. Who actually has it assigned. What it actually grants. And whether anyone assigned to it still does the job it was built for. Most orgs skip this for years, which is exactly why it's worth doing now.

Four steps from "nobody wants to touch it" to a clean audit trail — plus the Winter '27 tie-in.

Why permission sets pile up and nobody wants to touch them

Permission sets get created for a one-off project, a temporary access need, a role that later got restructured, and nobody circles back to remove them once the need passes. Each one starts to feel risky to touch, because nobody is fully sure who might be quietly relying on it. The safer-feeling choice is always to leave it alone and create a new one for the next need instead, which is exactly how orgs end up with more permission sets than active job roles.

A simple method to audit permission sets against real job roles

Pull a full list of permission sets with current assignment counts, from Setup or a report on permission set assignments

List current job roles or teams from an HR or org chart source of truth, not from Salesforce's own picture, since that view may be the stale one

For each permission set, check assigned users against that role list, and flag anyone assigned who has since moved to a different role, or a set assigned to nobody current at all

Check what each permission set actually grants, object permissions and field level security, watching for kitchen sink sets that grant far more than the role in front of you needs

Note permission sets with overlapping grants doing the same job under different names, a common sign of years of drift rather than deliberate design

Retiring unused permission sets without breaking anything mid-quarter

📋

Run a report on exactly who has each candidate permission set assigned right now, not from memory or an old spreadsheet

⏸

Deactivate before deleting where the tool allows it, or remove the assignment first and watch for a defined window, a sprint or a full pay cycle, before removing the set itself

📢

Tell the affected users' managers before removing anything, since a permission set nobody remembers creating might still be load bearing for one workflow that only runs at quarter close

🧩

Retire in small batches, not all at once, so a mistake affects a handful of people instead of the whole sales team the week they're closing pipeline

Tying this to the Winter '27 profile visibility change

Winter '27 already narrowed default visibility with Enable Profile Filtering, users without View All Profiles now see only their own profile name, covered in our September 4 release post. The same audit that surfaces unused permission sets is the natural moment to also confirm who actually has View All Profiles, and whether that list still matches who genuinely needs to see profile names across the org, instead of who happened to get it years ago.

Nobody circles back to remove a permission set once the need passes. That's not a discipline failure, it's the default outcome of a system that never forces the review — until something like Winter '27 gives you a reason to finally look.

Book a Health Check focused on security and permissions through our contact form, and follow TrueSolv on LinkedIn for more admin notes like this one.

Salesforce SecurityPermission SetsSalesforce AdminSalesforce Health CheckTrueSolv