[object Object]

The Feature

Summer ‘26 adds a Field Access tab at the bottom of each object in Object Manager. Lists every field with a clear view of exactly how access is granted — which profiles and permission sets give read/edit rights. The view is filterable by access type (Read, Edit, Hidden), grouped by field, and exportable to CSV for offline review. Each row shows: field API name, field label, granted profiles (comma-separated), granted permission sets, granted permission set groups, and whether the field is included in any field-level encryption policy. Click-through navigation jumps from a field row to the relevant profile or permission set in one click.

Why It Matters

Field-level security auditing was historically a slog — profile by profile, permission set by permission set. The new tab consolidates. Admins get a single pane for field-level security review. Pre-Summer ‘26, answering “who can see Account.AnnualRevenue” required either:

// Anonymous Apex hack - run as admin
Map<Id, String> profileAccess = new Map<Id, String>();
for (PermissionSet ps : [SELECT Id, ProfileId, Profile.Name
                         FROM PermissionSet
                         WHERE IsOwnedByProfile = true]) {
    for (FieldPermissions fp : [SELECT Field, PermissionsRead, PermissionsEdit
                                FROM FieldPermissions
                                WHERE ParentId = :ps.Id
                                AND Field = 'Account.AnnualRevenue']) {
        profileAccess.put(ps.ProfileId, fp.PermissionsEdit ? 'Edit' :
                                        fp.PermissionsRead ? 'Read' : 'None');
    }
}
System.debug(profileAccess);

Or Setup > Profiles, click into each, navigate to the object, find the field. The Field Access tab replaces both with one screen.

Compliance Use Case

Auditors ask: ‘Who can see this PII field?’ Before Summer ‘26, answering required spreadsheets and manual cross-referencing. Now it’s a click. For regulated industries, this is substantial audit-time savings. Concrete example: a SOC 2 Type II auditor requesting a list of all users with read access to Contact.SSN__c previously took an admin 4–6 hours to compile across 30+ profiles and 80+ permission sets. With the Field Access tab, the same request takes 5 minutes — filter the tab to that field, export, deliver. HIPAA covered entities, PCI environments, and GDPR-impacted EU deployments see the largest time savings because they typically have 50+ regulated fields under audit scope.

Practitioner Action

After Summer ‘26 upgrade, walk critical objects — anything with PII, financial data, compliance-sensitive fields. Document the current access posture. Remediate any over-permissioned fields. Re-baseline security policy. The recommended sequence:

  1. Inventory: list objects with regulated data (Contact, Account, Lead, Case, custom objects with PII)
  2. Export: pull the Field Access tab CSV for each object
  3. Review: identify fields with access through legacy profiles, deprecated permission sets, or unused permission set groups
  4. Remediate: remove access that doesn’t have a documented business justification
  5. Re-baseline: snapshot the cleaned access posture as the new ground-truth for ongoing audits

For programmatic use, the same data is available via the Tooling API:

SELECT Field, ParentId, Parent.Name, Parent.Profile.Name,
       PermissionsRead, PermissionsEdit
FROM FieldPermissions
WHERE Field = 'Account.AnnualRevenue'
ORDER BY Parent.Name

What Changed in 2026

The Field Access tab is part of a broader Summer ‘26 push toward security visibility. The release also added per-rule cost metrics to Sharing Health, audit-log search improvements, and new Restriction Rule templates for common compliance patterns (PCI cardholder data, HIPAA PHI markers, GDPR data subject categories). The cumulative effect: security auditing in Salesforce moves from a custom-script-and-spreadsheet exercise to a Setup-native workflow.

Common Failure Modes

Reading the tab without understanding inherited access. A field shown as accessible “via Permission Set X” might also be accessible through a permission set group that includes X — removing X doesn’t necessarily revoke access. Always check permission set group memberships before assuming a remediation worked. Second: forgetting that profile-level field access is governed by both the profile’s own field permissions and the permission sets assigned to users with that profile. The tab shows both; the access summary is the union.

What to do this week

Pull the Field Access tab CSV for one PII-bearing object — Contact is usually the highest-impact starting point. Compare against your documented access policy. File any gaps as remediation tickets. The first audit you walk through with this tooling will pay back the configuration time many times over.

[object Object]
Share