Field-Level Security
Field-Level Security in Salesforce is the per-field Read and Edit permission that decides whether a user can see and change a specific field on a specific object.
Definition
Field-Level Security in Salesforce is the per-field Read and Edit permission that decides whether a user can see and change a specific field on a specific object. FLS is configured per Profile and per Permission Set, and it operates independently of the object-level CRUD permissions that decide whether a user can access the record at all. A user with full Read access to Opportunity but no FLS on the Amount field sees an Opportunity record with the Amount field blank or hidden, even when the field actually contains a value.
Field-Level Security is the granular layer that makes Salesforce usable for compliance-regulated organizations. Most data-protection regimes (GDPR, HIPAA, PCI-DSS, financial-services regulations) require that sensitive fields be hidden from users who do not need them, even when those users can access the record. Without FLS, every user with object access would see every field on every record, which is incompatible with any meaningful data-protection program. FLS lets you grant access to the Opportunity but hide the AnnualRevenue field, grant access to the Patient record but hide the Diagnosis field, grant access to the User record but hide the Compensation field. The behavior is silent by design.
How Field-Level Security controls per-field visibility
How FLS evaluates
For every record a user accesses, the platform applies FLS field-by-field. A field with Read=false is omitted from the API response, returned as null in SOQL, hidden from the page layout, hidden from list views, and excluded from reports. A field with Edit=false is visible but not editable; the UI grays it out and the API rejects attempts to write to it. FLS evaluation is fast (cached per session) but the cascading impact on reports, formulas, and integrations is large. A formula field that references a hidden source field returns null for users who lack FLS on the source, which can break downstream logic in non-obvious ways.
FLS vs Object Permissions
FLS sits below object-level CRUD permissions in the access stack. Object permissions decide whether a user can touch the object at all (Read=true means "can see records of this object"); FLS decides which fields they see within those records. A user with no Read on Account cannot see any Account at all, regardless of FLS. A user with Read on Account but no FLS on AnnualRevenue sees Accounts with the AnnualRevenue column missing. Most permission-design conversations get confused on this stack; the cleanest mental model is "Object permissions decide access; FLS decides visibility of specific fields once access is granted."
Default FLS for new fields
When a Salesforce admin creates a new custom field, the FLS dialog at the end of field creation asks which Profiles and Permission Sets should have Read and Edit access to the new field. The default is "no Profiles have access" for security reasons, which means a newly created field is invisible to every user until somebody explicitly grants FLS. This is the source of the most common Salesforce support ticket in any production org: "I just made a new field but it is not showing up." The cause is almost always missed FLS at field-create time. Build the habit of granting FLS to the relevant Profiles or Permission Sets at field creation, not as a follow-up step.
Auditing FLS across the org
Auditing FLS across an enterprise org is harder than it looks. FLS lives on every Profile and every Permission Set, and the union of all FLS assignments per User produces their effective field access. The platform offers a Field Accessibility view (Setup > Object Manager > [object] > Fields > Field Accessibility) that shows which Profiles can see each field, but the view does not cover Permission Set assignments cleanly. Most orgs run audit reports through the Metadata API or third-party tools (Salesforce Security Center, Field Trip on AppExchange) to get a comprehensive view of who can see what. Quarterly FLS audits should be on the security team's calendar for any org handling regulated data.
FLS and Page Layout
Page Layout settings (Required, Read-Only) interact with FLS in non-obvious ways. A field with Required = true on Page Layout but Read = false on FLS produces an unsaveable record: the user cannot see the field, so cannot populate it, but the layout demands it. A field with Read-Only on Page Layout but Edit = true on FLS surfaces a contradictory permission model. The cleanest design aligns the two layers: if FLS grants Edit, Page Layout should not be Read-Only; if FLS grants only Read, Page Layout cannot make the field Required. Validate this alignment any time you add or change a field's FLS or Page Layout settings.
Encryption and FLS interaction
Salesforce Shield Platform Encryption changes how FLS behaves for encrypted fields. Encrypted fields display as masked or hidden values to users without the View Encrypted Data permission, layered on top of standard FLS. The combination of Shield Encryption and FLS lets compliance-heavy orgs build multi-layered field protection: FLS hides the field from users who do not need it, Encryption masks the field for users who need limited visibility, and the View Encrypted Data permission grants full clear-text access to a small set of authorized users. Configure these layers explicitly; the default Shield Encryption setting does not assume any specific FLS policy.
FLS impact on reports and integrations
Reports honor FLS. A user running a report sees only the fields they have FLS Read on; fields without FLS are silently excluded from the report's column list. This produces invisible inconsistencies: two users running the same report can see different columns and different aggregate values. SOQL queries through the API also honor FLS (when the API client respects the calling user's permissions, which most clients do). Integration users frequently need broader FLS than human users; build a dedicated Integration User Profile with FLS on every field the integration touches, and audit that Profile carefully because its broad access makes it a high-value target if compromised.
How to configure Field-Level Security
Configuring Field-Level Security is one of the most-done admin tasks in any Salesforce org. The configuration is per-field per-Profile, so the work multiplies fast on orgs with many custom fields and many Profiles.
- Open Setup and navigate to the field
Setup > Object Manager > select the object > Fields & Relationships > select the field. The field detail page has a Set Field-Level Security button at the top.
- Click Set Field-Level Security
The button opens a matrix of Profiles with Read and Edit checkboxes for the field. The matrix is per-field, not per-Profile, so you set FLS for one field across all Profiles at once.
- Set Read and Edit per Profile
Tick Read for Profiles that should see the field, Edit for Profiles that should also change it. Default to least-privilege; grant access only to Profiles that need it.
- Save
Click Save. The change takes effect immediately for all users on those Profiles.
- Repeat for Permission Sets
Permission Sets carry their own FLS. Setup > Users > Permission Sets > select the Permission Set > Field-Level Security configures FLS through Permission Sets, which is the cleaner pattern for granular field access.
- Test with representative users
Log in as a user on a Profile or Permission Set whose FLS you just configured and confirm the field appears (or does not appear) as expected.
- Default FLS for new fields
Configure at field creation. The dialog at the end of field creation lets you grant FLS to specific Profiles immediately.
Required for the field to appear at all.
Required for the field to be writable. Read=true with Edit=false produces a read-only field.
- FLS is invisible to users. A user who cannot see a field cannot tell whether the field is blank or whether they lack access. This is a feature, not a bug, but it produces confusing "the field is missing" support tickets.
- Required-on-Page-Layout + Read=false in FLS produces an unsaveable record. Align Page Layout and FLS settings to prevent this.
- FLS configured per Profile multiplies fast. Prefer FLS through Permission Sets so granting field access does not require Profile-level edits.
- Integration users typically need broader FLS than human users. Build a dedicated Integration User Profile and audit it carefully.
Trust & references
Cross-checked against the following references.
- Field-Level SecuritySalesforce Help
- Security OverviewSalesforce Help
Straight from the source - Salesforce's reference material on Field-Level Security.
- Field-Level SecuritySalesforce Help
Hands-on resources to go deeper on Field-Level Security.
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-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…