Field Accessibility
Field Accessibility is the Salesforce Setup view that shows, for any given field on any object, exactly which users can see it and edit it based on the combination of profile, permission set, record type, and page layout assignments.
Definition
Field Accessibility is the Salesforce Setup view that shows, for any given field on any object, exactly which users can see it and edit it based on the combination of profile, permission set, record type, and page layout assignments. The page presents a single field's effective access across every profile and record type in the org as a color-coded matrix, exposing the often-confusing interaction of field-level security with page layouts. It is the canonical answer to "why can't this user edit this field?" and the fastest path to verifying that a configuration change produced the intended permission outcome.
The view does not change permissions; it only reports the current state. Administrators use it to diagnose access issues raised by end users and to audit field exposure before releasing a new field or record type. The matrix accounts for the layered model: field-level security (FLS) on the profile or permission set, the page layout's read-only or required setting, and any record-type-specific page layout assignment. The combination of these layers produces the user's effective access, which is what Field Accessibility surfaces.
How Field Accessibility computes effective access
The layered access model
A user's access to a field is the combination of three layers. Field-Level Security (FLS) on the profile or permission set defines whether the user can see and edit the field at all. The page layout (which is assigned per profile and per record type) defines whether the field appears as editable, read-only, or required on a given record. The record type assignment defines which page layout the user sees. Field Accessibility computes the final effective access by combining all three.
Reading the matrix
The Field Accessibility page presents a grid: rows are record types, columns are profiles. Each cell shows the effective access for that combination: Editable, Read-Only, Required, or Hidden. Clicking a cell drills into the components: which FLS setting applies, which page layout is assigned, which layout property the field has. The drill-down is the diagnostic mechanism; the matrix is the inventory.
Hidden versus Read-Only
Hidden means the user cannot see the field at all; it does not appear on the page, in reports, in SOQL, or in the API for that user. Read-Only means the user sees the value but cannot change it. The difference matters for compliance: a regulated field that must not be visible to certain users needs to be Hidden, not Read-Only. Field Accessibility distinguishes the two clearly in its display.
When FLS and page layout disagree
The strictest layer wins. If FLS is Read-Only but the page layout marks the field Editable, the user gets Read-Only. If FLS is Edit but the page layout marks it Required, the user gets Required. If FLS is Hidden, the user does not see the field regardless of page layout. This is the source of most "why is this field read-only" questions: an admin updated the page layout but not the FLS, so the FLS still blocks the edit.
Record types as a multiplier
Record types add a dimension. A field can be Editable for record type A and Read-Only for record type B, because each record type has its own page layout assigned per profile. Field Accessibility surfaces this clearly with one row per record type. Audit the matrix every time you add a record type; new record types come with a default page layout that may not match the field-level security you intended.
Permission sets layered on top
Permission sets add additional FLS on top of the profile's FLS. A user gets the more permissive of the two: if the profile says Read-Only and the permission set says Edit, the user gets Edit. The Field Accessibility view shows the effective access including permission set contributions, but the drill-down may require investigation to identify which specific permission set is adding the access.
Auditing before deploying
Before deploying a new field or changing a record type configuration, audit Field Accessibility for the affected combinations. Capture screenshots of the expected state and the post-deployment state. Discrepancies between expected and actual often surface a missed permission set assignment or a page layout that was changed but not committed to source control. This is the kind of pre-deployment check that prevents user-visible regressions.
Diagnose field access with Field Accessibility
Using Field Accessibility is a diagnostic workflow, not a configuration one. The steps below cover the troubleshooting and audit patterns that turn the page from a curiosity into the canonical access-verification tool.
- Navigate to Field Accessibility
Setup > Field Accessibility, or open the object in Object Manager and click the Field Accessibility link in the fields list. The matrix loads with all profiles and record types.
- Filter to the relevant scope
Use the View by dropdown to filter by Field, Profile, or Record Type. For most troubleshooting, View by Field is the starting point.
- Identify the problematic cell
Find the cell showing unexpected access. Click it to drill into the components: FLS setting, page layout name, layout property.
- Trace the strictest layer
The bottleneck is whichever layer shows the more restrictive setting. FLS Hidden beats everything; page layout Read-Only beats FLS Edit; record type assignment selects the layout.
- Update the bottleneck
Navigate to the offending layer (Profile, Permission Set, or Page Layout) and update the setting. Return to Field Accessibility and refresh to confirm the matrix now shows the intended access.
- Test as the user
Use Login As to impersonate an affected user and verify the change. The matrix shows expected access; impersonation confirms actual access matches.
- Document the configuration
For complex orgs, capture the Field Accessibility matrix in a screenshot or export. Compliance audits expect a record of access for sensitive fields; the matrix is the canonical artifact.
Shows one field across all profiles and record types. The standard troubleshooting starting point.
Shows all fields for one profile. Useful for auditing what a profile can see on an object.
Shows all fields for one record type. Useful when launching a new record type to verify access.
Clicking a cell shows the contributing FLS, page layout, and layout property. The diagnostic detail layer.
Matrix is computed; after changing FLS or layout, refresh the page to see the updated effective access.
- The matrix is read-only. To change access, navigate to the profile, permission set, or page layout; Field Accessibility just reports the state.
- Permission sets are layered on profile FLS. A user with multiple permission sets may have access that the profile alone would not grant. Trace each contributing permission set.
- Adding a record type creates a default page layout assignment that may not match your intended FLS. Audit Field Accessibility after every record type change.
- Some fields (system audit fields like CreatedDate, formula fields) have permanent Read-Only properties that cannot be made Editable through FLS. Field Accessibility shows the cap, but the underlying constraint is the field type.
- The matrix display can become unwieldy for orgs with many profiles and record types. Filter aggressively; trying to see everything at once obscures the specific cell you care about.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. Why is understanding Field Accessibility important for Salesforce admins?
Q2. What is the primary benefit of Field Accessibility for Salesforce administrators?
Q3. In which area of Salesforce would you typically find Field Accessibility?
Discussion
Loading discussion…