[object Object]

The Summer ‘26 Feature

The Field Access tab in Object Manager consolidates: every field on an object, where access is granted, which profiles, permission sets, and permission set groups control it, and whether the access is read or edit. It replaces manual cross-referencing through the legacy Profile and Permission Set pages and is the first FLS surface that’s actually usable for an audit at scale. The tab is searchable, filterable by access level, and exportable to CSV for offline analysis.

Field Access tab columns (Summer '26):
  Field | API Name | Type | PII Class | Read | Edit | Granted Via | Last Modified

Audit Cadence

Quarterly review at minimum; monthly for orgs with active integrations or new agent deployments. Export the Field Access map. Compare against your data classification (PII, PHI, financial, confidential). Remediate over-permissioned access by removing edit on read-only fields, removing read on fields no profile actually needs, and consolidating duplicate grants into a single Permission Set.

Audit checklist:
  [ ] Every PII field has a documented access list
  [ ] No "View All Fields" granted on standard objects
  [ ] FLS matches sharing model intent (no read-but-not-share gaps)
  [ ] Integration users have minimum-necessary FLS
  [ ] Agent Connected App users audited separately
  [ ] Deprecated fields confirmed unused before removal

Permission Set Strategy

Move away from profile-level FLS; use Permission Sets and Permission Set Groups. Grants are granular, composable, and portable across profiles. The Summer ‘26 Field Access tab works across both, so migration pays dividends in audit simplicity. The recommended pattern: minimal “skinny” profiles (login + base UI permissions only) and stack Permission Set Groups for functional access. Document each PSG with a description that names the business role it represents — “AE West Region”, “CSM Tier 2”, “Finance AR” — so the next admin can read intent.

AI Implications

AI agents see fields through the running user’s FLS, and Apex Actions invoked by an agent should use WITH USER_MODE so the agent can never read past the caller’s FLS. Over-permissioned users mean over-exposed AI. The audit becomes more urgent because an agent can query and reason across everything the user can, in seconds, then expose it via natural-language output. Tightening FLS directly reduces AI data exposure — and reduces the blast radius of prompt injection attacks that try to exfiltrate fields the agent shouldn’t have seen.

// Correct pattern: agent Apex Action enforces caller's FLS
@InvocableMethod(label='Get Account Snapshot')
public static List<Result> run(List<Input> inputs) {
    List<Account> accts = [
        SELECT Id, Name, AnnualRevenue, Industry
        FROM Account WHERE Id IN :ids
        WITH USER_MODE     // critical
    ];
    // ...
}

Common Failure Modes

  • Granting FLS on profiles “to make integration just work” — the access becomes invisible to the Permission-Set-centric audit and outlives its purpose.
  • Forgetting that WITH USER_MODE must be opted in; legacy Apex defaults to system mode and bypasses FLS.
  • Over-trusting “View All Data” for support roles — it bypasses FLS entirely and produces unauditable data access.
  • Ignoring the integration user. Integration users typically hold the broadest FLS in the org and are the highest-risk single account.

What Changed in 2026

Beyond the Field Access tab, Summer ‘26 added FLS-aware error reporting in the SOQL response (the API now identifies which field caused a security exception, replacing the old generic message) and a FieldPermissions Tooling API endpoint that powers external audit tooling.

What to Do This Week

Open Object Manager on your highest-PII custom object, click the new Field Access tab, export to CSV, and identify three fields with access broader than they need.

[object Object]
Share