Permissions & Access Review

SALESFORCE SENSITIVE FIELD EXPOSURE REVIEW.

Identify fields that may contain sensitive data and review who can see or edit them through profile and permission set access — before access issues grow.

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

A Salesforce sensitive field exposure review means identifying fields that may contain confidential, regulated, financial, personal, or business-sensitive data, and then reviewing who can see or edit them through available profile and permission set access.

Sensitive field exposure is not just a security topic. It is a business governance topic. Fields containing compensation data, health-related records, customer financial information, or internal performance data may be visible to broader user populations than business owners intended — sometimes because of permission sprawl, cloned profiles, or historical access grants that were never reviewed.

Why It Matters

WHY FIELD-LEVEL SECURITY MATTERS.

Field-level security is Salesforce's primary control over who can see and edit individual fields. It operates at two levels — Read access and Edit access — and both can grant meaningful exposure:

  • Read access allows a user to see a field's value in the UI, in reports, and in list views
  • Edit access allows a user to change a field's value directly
  • No access means the field is hidden from the user — they cannot see or edit it

The most-permissive-grant rule means that if a user has a profile with no access to a field, but also has a permission set that grants Read access, they can see the field. Reviewing FLS only at the profile level understates exposure when permission sets are in use.

Checklist

SENSITIVE FIELD EXPOSURE CHECKLIST.

Identifying sensitive fields

  • Fields with names or labels suggesting financial data — salary, commission, revenue, discount, credit
  • Fields with names suggesting personal or health-related data — date of birth, health status, personal ID numbers
  • Fields labeled as confidential or restricted in the field description or help text
  • Fields on objects that carry business-sensitive data — HR objects, financial transaction objects, legal case objects
  • Fields with encryption or masking configurations that indicate intended sensitivity

Profiles, permission sets, and FLS

  • List all profiles with Read or Edit access on each sensitive field
  • List all permission sets with Read or Edit access on each sensitive field
  • Count active users covered by each profile and permission set with sensitive field access
  • Flag cases where the exposure is broader than the field's intended user audience
  • Note any integration user profiles or API-only profiles with FLS access to sensitive fields

External and community user exposure

  • Check whether sensitive fields are accessible through Experience Cloud or portal page layouts
  • Review FLS for guest user profiles and community user profiles separately
  • Note any sensitive fields that appear on community record detail components

Permission set sprawl and sensitive fields

  • Identify permission sets that grant access to sensitive fields but have broad or unclear assignment scopes
  • Look for permission sets assigned to users whose role does not require sensitive field access
  • Flag users with multiple permission set grants that together create sensitive field exposure not intended by any individual set

Relevant Workbook

Permission & FLS Audit

Permission & FLS Audit maps profiles, permission sets, FLS across fields, user assignments, and access-risk signals into a review-ready XLSX workbook — supporting sensitive field exposure review before access changes are made.

Learn more →Run diagnostic →View sample workbook →
Limitations

WHAT A SENSITIVE FIELD REVIEW CANNOT PROVE.

A FLS-based sensitive field review has important limitations:

  • FLS does not restrict all API access — some integration patterns bypass FLS, particularly when running as System Administrator profiles or with certain API access configurations
  • Report and list view access may surface field values even when FLS restricts direct record access — separate review of report permissions may be needed
  • Platform encryption and field masking configurations are not the same as FLS and require separate assessment
  • Compliance determinations require legal and regulatory context that metadata review cannot provide

KeelCadence does not certify compliance with any regulatory framework. It provides review signals. See also security and IT review.

FAQ

FREQUENTLY ASKED QUESTIONS.

What is sensitive field exposure in Salesforce?

Sensitive field exposure in Salesforce means that users — or user types — can read or edit fields containing confidential, regulated, financial, personal, or business-sensitive data through their profile or permission set access. A sensitive field exposure review identifies which profiles and permission sets expose those fields and to how many users.

How do I check who can see sensitive fields in Salesforce?

Review field-level security for the field across all profiles and permission sets in the org. FLS has two dimensions — Read access and Edit access. Both should be reviewed. The most-permissive-grant rule means a permission set grant can override a profile restriction, so reviewing only profiles is not sufficient.

Is field-level security enough to protect sensitive data?

Field-level security is an important control, but it is not the only layer. FLS restricts access through the Salesforce UI and API by default, but some API access patterns bypass FLS checks. Integration users with elevated object permissions may be able to read or update fields regardless of FLS settings. A sensitive field review should include API and integration access alongside standard user access.

Should external users be included in sensitive field reviews?

Yes. External users, community users, and guest users should be reviewed separately. They may have access to sensitive fields through portal page layouts, community components, or permission sets assigned specifically for external access. The consequences of over-exposure to external users may be higher than for internal users.

Can KeelCadence certify compliance?

No. KeelCadence provides read-only diagnostic workbooks and review signals. It does not certify compliance with any regulatory framework. Compliance determinations require qualified human review, legal context, and organizational controls that go well beyond what metadata review can provide.

Review Before Change

CREATE A REVIEW-READY WORKBOOK BEFORE MAKING SALESFORCE CHANGES.

Run a read-only KeelCadence diagnostic to surface metadata, access, automation, field, and readiness signals before cleanup, UAT, imports, handoff, or change work.

Run Permission & FLS Audit →View Sample Workbook

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

Home/Resources/Salesforce Sensitive Field Exposure Review

Trust & Security

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.