Salesforce Access Review · Answer Guide

SALESFORCE PERMISSION AUDIT CHECKLIST.

A Salesforce permission audit reviews profiles, permission sets, object permissions, field-level security, external user access, assigned users, unused permission sets, and over-privileged access — before cleanup, governance, or security work begins.

Read-only diagnostics · Review-ready workbooks · No package install · No Connected App

A Salesforce permission audit should review profiles, permission sets and permission set groups, object permissions, field-level security, external and community user access, assigned users, inactive or unassigned permission sets, and over-privileged access patterns.

The point of the audit is visibility before change. You are not removing access on sight — you are surfacing review candidates so the right access can be validated with stakeholders before cleanup, governance review, or security work begins.

01 — Why It Matters

WHY SALESFORCE PERMISSION AUDITS MATTER.

Most orgs do not have an access problem because someone designed them badly. They develop one over time, as new projects add exception access, users change roles, and permission sets stack on top of profiles. Eventually it becomes hard to answer a simple question: who actually has access to what?

What a permission audit helps you catch

  • Over-privileged users who accumulated access over time
  • Profile sprawl across too many similar profiles
  • Permission set stacking that elevates access invisibly
  • Sensitive field exposure through field-level security
  • External and community user exposure
  • Compliance and governance review readiness
  • Inherited org risk where access history is undocumented
02 — The Checklist

SALESFORCE PERMISSION AUDIT CHECKLIST.

Work through these steps by category, in order. Each one surfaces review candidates rather than conclusions — validate findings with owners before changing anything.

01 — Baseline access

Establish what every user starts with before any add-on access is layered on.

  • Review profiles and their assigned users.
  • Identify near-duplicate profiles that could be consolidated.
  • Review the default access each profile grants on core objects.

02 — Layered access

Permission sets and groups stack on top of profiles — this is where most invisible elevation happens.

  • Review permission sets and permission set groups.
  • Identify users with excessive permission stacking.
  • Identify unassigned or unused permission sets.
  • Look for duplicate or near-duplicate access patterns.

03 — High-risk permissions

Broad object and administrative permissions deserve a separate, explicit pass.

  • Review View All / Modify All object permissions.
  • Review admin-only or high-risk system permissions.
  • Confirm who can manage users, permissions, and sharing.

04 — Sensitive data exposure

Field-level security can expose data that a page layout hides — review it directly.

  • Check field-level security on sensitive fields.
  • Review external / community / guest user access.
  • Confirm sensitive fields are not readable through unexpected profiles or sets.

05 — Document & validate

The audit produces review candidates, not conclusions — record them and assign owners.

  • Document findings and remediation owners.
  • Validate each candidate with the role or process owner before changing access.
  • Set a recurring cadence so the review repeats instead of drifting.
03 — Sensitive Data

FIELDS TO TREAT AS SENSITIVE.

Field-level security matters most on the fields that carry risk. A field can be hidden from a page layout while still being readable through FLS, so review these field types specifically across profiles and permission sets.

Common sensitive field types

  • SSN / tax ID
  • Salary / compensation
  • Health / insurance
  • Credit score
  • Bank / payment data
  • Personal contact information
  • Authentication or credential-related fields

Sensitivity depends on your business context. Define what counts as sensitive in your org, then review FLS on those fields specifically.

04 — Pitfalls

COMMON PERMISSION AUDIT MISTAKES.

Most incomplete audits fail in the same predictable ways. Avoiding these keeps the review honest.

What to watch for

  • Only checking profiles and ignoring permission sets
  • Ignoring permission set stacking across multiple assignments
  • Ignoring field-level security exposure
  • Ignoring external and community users
  • Assuming assigned access equals active use
  • Treating the audit as a one-time cleanup rather than a recurring review
05 — Manual vs. Diagnostic

MANUAL REVIEW VS. A READ-ONLY DIAGNOSTIC.

You can run this checklist entirely by hand. The difference a read-only diagnostic makes is coverage and repeatability — it surfaces the same candidates every cycle so you spend your time deciding, not gathering.

What to compareManual reviewWith Permission & FLS Audit
CoverageEasy to stop at profiles and miss stacked permission setsMaps profiles, permission sets, and groups together in one pass
Field-level securityFLS is reviewed field-by-field, profile-by-profileSurfaces sensitive-field exposure across profiles and sets at once
Permission stackingHard to see cumulative access from multiple assignmentsHighlights over-privileged users from layered assignments
RepeatabilityRe-done by hand each cycle; results vary by reviewerSame read-only export each time, easy to compare run-over-run
OutputNotes and ad-hoc spreadsheetsStructured, review-ready XLSX workbook
Decision-makingReviewer decides as they goSurfaces candidates only — admins and owners still decide

Either way, the audit surfaces review candidates — it does not decide whether access is appropriate. That validation stays with the admins and stakeholders who know each role.

06 — Faster Review

A FASTER WAY TO REVIEW SALESFORCE PERMISSIONS AND FLS.

KeelCadence Permission & FLS Audit is a read-only diagnostic that maps profiles, permission sets, object permissions, field-level security exposure, user-assignment patterns, over-privileged access, and review candidates into a downloadable XLSX workbook.

It surfaces the patterns this checklist looks for so you can review and prioritize them — it does not decide whether access is appropriate. That validation stays with the admins and stakeholders who know each role and business process.

Relevant Workbook

Permission & FLS Audit

Permission & FLS Audit maps profiles, permission sets, object permissions, field-level security exposure, user assignments, and over-privileged access into a review-ready workbook.

What This Checklist Does Not Replace

WHAT THIS CHECKLIST DOES NOT REPLACE.

A permission audit checklist is a focused access diagnostic, not a complete Salesforce security review. It will not decide whether access is appropriate for every role, department, or business process.

The goal is to surface review candidates — broad object access, sensitive field exposure, stacked permissions, unused permission sets, and external exposure — so they can be validated before you change or remove anything.

Related Resources

RELATED GUIDES.

FAQ

FREQUENTLY ASKED QUESTIONS.

How often should you audit Salesforce permissions?
Most teams review permissions on a recurring cadence — often quarterly or twice a year — and again before major events such as an inherited-org handoff, a security or governance review, a role redesign, or an external-user rollout. Access drifts continuously as users change roles and permission sets stack up, so a one-time cleanup is rarely enough. The goal is to keep over-privileged access and permission sprawl visible over time, not just once.
What is the difference between a profile and a permission set?
A profile defines a user's baseline access, and historically every user has exactly one. Permission sets and permission set groups add access on top of that baseline and can be assigned to many users. A useful permission audit reviews both together, because users frequently receive elevated access through layered permission sets even when their profile looks restricted.
What fields count as sensitive?
Sensitivity depends on your business context, but common examples include SSN or tax ID, salary and compensation, health and insurance data, credit scores, bank and payment details, personal contact information, and authentication or credential-related fields. The key is to define sensitivity for your org and then review field-level security on those fields specifically, since a field can be hidden from a layout while still exposed through FLS.
Should permission audits include external users?
Yes. External, community, and guest users often have different exposure patterns from internal users, and they are a common source of unintended access. A permission audit should review external profile object access, field visibility for external users, and any publicly exposed record access patterns available in metadata, separately from internal access.
Next Step

Turn this access review into a workbook.

Once you know what to review, run the read-only Permission & FLS Audit to map profiles, permission sets, FLS exposure, and over-privileged access into one review-ready workbook. See the free on-screen summary before purchase.

Opens permissions.keelcadence.com. Best run from desktop, since the diagnostic uses your active Salesforce browser session. On mobile, view the sample workbook or save this page for later.

Read-only · No package install · No Connected App setup · No Salesforce writes

KeelCadence uses session cookies and Google Analytics 4 for site usage insights. GA4 does not receive Salesforce credentials, Org IDs, Report IDs, or payment data. You can opt out for this browser.