Field-Level Security
Field-Level Security (FLS) is a per-field access control in Salesforce.
Definition
Field-Level Security (FLS) is a per-field access control in Salesforce. It determines, per profile or permission set, whether a user can read a specific field's value or edit it. FLS is independent of object permissions and page layouts - a user may have read/edit access to the Account object and still have a specific field like Account.AnnualRevenue hidden or read-only via FLS.
In plain English
“Field-Level Security decides which fields each user can actually see and change. Object permissions say "you can open Accounts," but FLS goes a level deeper: "yes you can open Accounts, but don't show this person the Annual Revenue field." Admins set it per profile or permission set, field by field.”
Worked example
At Silver Lake Credit Union, admins need loan officers to see Account.CreditScore but hide it from general tellers. Both profiles already have Read access on Account. The admin opens the Account object's Fields & Relationships section, clicks Set Field-Level Security on CreditScore, grants Read+Edit to the Loan Officer profile, and sets the Teller profile to hidden. The field disappears entirely from the Teller UI - layouts, reports, list views, and API calls all respect the FLS setting.
Why Field-Level Security matters
Field-Level Security is one of three layered access controls in Salesforce: object permissions (can the user access the object at all?), record-level sharing (which records of that object?), and FLS (which fields on the record the user is allowed to see). FLS is defined in Setup via the field's detail page, the profile/permission-set Field Permissions section, or the Field Accessibility tool, and applies uniformly across the UI, reports, list views, SOQL via the REST/SOAP API, and Apex (with the `WITH SECURITY_ENFORCED` clause or `Security.stripInaccessible`).
FLS is distinct from page-layout visibility: a field can be on a layout but hidden by FLS (the UI omits it entirely), or removed from the layout but still accessible via FLS in reports and API. The Salesforce recommended practice is to prefer Permission Sets for granting FLS rather than Profiles because permission sets can be combined via Permission Set Groups and are easier to audit. Apex classes that don't respect `WITH USER_MODE`/FLS enforcement are a common security-review finding - protecting FLS across both UI and code is essential to maintaining sensitive data compartments.
How to set up Field-Level Security
Field-Level Security (FLS) controls which fields a profile / permission set can see and edit, independent of the page layout. It's the most-confused part of the Salesforce security model — page layouts dictate visual placement, FLS dictates whether the data is exposed at all.
- Decide where to set it: Profile, Permission Set, or Field-by-field
Modern best practice: grant FLS via Permission Sets, not Profiles. Profile FLS is the floor; permission sets layer on top.
- Per-field path: Object Manager → object → Fields & Relationships → [field] → Set Field-Level Security
Useful when adding one field; lets you tick Visible / Read-Only across all Profiles in one screen.
- Per-permission-set path: Setup → Permission Sets → [set] → Object Settings → [object] → Field Permissions
Better for managing many fields at once. Each row shows Read / Edit checkboxes per field.
- Set Visible (Read access)
Untick to hide the field entirely — UI, reports, list views, API. "Hidden" is total.
- Set Read-Only
Tick to make the field read-only via this profile/permission set. Page layouts can override Read-Only by making the field editable on the layout — confusing but documented.
- Save and verify
Open the record as a user assigned to that profile/permission set. Check the field is hidden / read-only as expected — and that reports don't expose what FLS hides.
Read access. Off = field is completely hidden — UI, reports, list views, API.
User can see but not edit. Page Layout can override this for that layout.
Profile FLS is the floor. Permission Sets layer on top with grants only — they cannot remove access.
- FLS hides the field everywhere — including reports, dashboards, Apex SOQL queries (the field returns null for users without access), and APIs. Test reports after changing FLS to make sure nothing breaks.
- Page Layout's "Read-Only" toggle can override FLS Read-Only for that layout. Layouts can grant Edit even when FLS says Read-Only — common source of "why can this user edit this field?" tickets.
- Universally Required fields (set at the field definition) override FLS. If a field is required, FLS can't make it invisible — Salesforce treats hidden + required as a contradiction.
How organizations use Field-Level Security
Hides Account.CreditScore from the Teller profile via FLS while keeping it visible to Loan Officers - the same field, same record, different per-profile visibility.
Uses FLS on sensitive HR fields (Salary, Personal Email, Emergency Contact) and enforces it in Apex with `WITH USER_MODE` so custom screens never accidentally expose fields that the UI would block.
Audits FLS via Permission Set Groups quarterly - any new sensitive field requires an explicit security review on which profile gets Edit vs. Read vs. Hidden.
Trust & references
Straight from the source - Salesforce's reference material on Field-Level Security.
- Set Field Permissions in Permission Sets and ProfilesSalesforce Help
- Set Field-Level Security for a Field on All ProfilesSalesforce Help
Test your knowledge
Q1. Why is understanding Field-Level Security important for Salesforce admins?
Q2. What is the primary benefit of Field-Level Security for Salesforce administrators?
Q3. Can a Salesforce admin configure Field-Level Security without writing code?
Discussion
Loading discussion…