What Does This Permission Set Actually Grant? A Faster Salesforce Audit
- Architect
- 23 hours ago
- 2 min read
Permission sets accumulate. Someone creates "Sales Ops Extended" to fix one access problem, someone else adds a field permission to it eight months later to fix a different one, and by the time you inherit the org, nobody can tell you exactly what it grants without opening it up and checking three separate Setup pages by hand.
One view instead of three
Permission Sets Reporting Helper, part of Power User Toolkit, picks any permission set apart into a single accordion view:
User Permissions — every system-level permission that's actually checked (API Enabled, Modify All Data, and the rest), instead of a full list where you have to hunt for the ones that are on.
Object Permissions — a flat table, one row per object, with Read, Create, Edit, Delete, View All, and Modify All shown as columns you can scan at a glance.
Field Permissions — a tree grid grouped by object, each field showing Read and Edit access, so you're not paging through Field-Level Security one object at a time.
All three sections are open by default, so the full picture of what a permission set does is visible in one scroll instead of three separate page loads. That's a complete Salesforce permission set audit without leaving one screen.
Export it when you need it in writing
Each section exports to its own CSV, named after the permission set. That matters more than it sounds — a security review or an access recertification usually wants documentation, not just a screen you looked at once. Having a clean, timestamped export means the audit trail exists without extra work.
When this actually saves time
Access recertification. Reviewing what every permission set grants, on a schedule, is exactly the kind of repetitive check this replaces a manual walkthrough for.
Inheriting an org. New admin, unfamiliar permission set names, and a need to understand the access model fast.
Before deleting a permission set. Confirming what it grants — and by extension, what removing it would take away — before you clean it up.
Debugging "why can't this user do X." Checking each of their assigned permission sets individually is slow; this makes each one fast to reason about.
None of this requires a new object or a new place to store data — it reads what's already in the org and organizes it into something you can actually use.
For related access-governance checks, see Who Can Actually See That Field? and The Permission Set Assignment About to Expire That No One Noticed. Or start at the Power User Toolkit overview.
Comments