If you’ve ever wondered why a Salesforce user can view a record but can’t see certain fields on it — or why a sales rep can’t edit a salary field even with full object access — you’ve encountered field level security in Salesforce in action.
Field level security (FLS) is one of the most powerful and essential data protection tools available to Salesforce administrators. While most admins are familiar with object-level and record-level security, field level security often doesn’t get the attention it deserves. And that’s a mistake — because without properly configured FLS, sensitive data like Social Security Numbers, salaries, or confidential deal terms can be exposed to the wrong users.
In this complete guide, we’ll walk you through everything you need to know about field level security in Salesforce: what it is, why it matters, how to set it up step by step, best practices, and common mistakes to avoid.
Field level security in Salesforce controls whether a user can view or edit the value for a particular field on an object’s record. Unlike page layouts — which only control field visibility on detail and edit pages — field level security secures field access across the entire application, including related lists, list views, reports, search results, and API calls.
Think of it this way: page layouts are like curtains that hide a field from view on a specific page. Field level security is like a locked door — it physically prevents a user from accessing that field data anywhere in the system, whether through the UI, reports, formula fields, or integrations.
Key insight: If you hide a field using a page layout, users can still access its value through formula fields or reports. Field level security truly restricts access across all channels.
A Simple Analogy
Picture a large mansion with 200 rooms. Everyone has access to the mansion (the object), but each room (each field) has its own lock and key. Some rooms are open to all guests; others require a special key based on a person’s role or invitation. Field level security is the system that manages which keys each guest get
Why Field Level Security in Salesforce Matters
Organizations store highly sensitive data in Salesforce — employee salaries, Social Security Numbers, contract terms, medical information, and more. Without proper FLS configurations, this data is vulnerable to accidental or malicious exposure.
Here is why field level security should be a top priority for every Salesforce admin:
- Data Privacy: Ensures users only see data relevant to their role, reducing unnecessary exposure of sensitive information.
- Regulatory Compliance: Helps meet requirements under GDPR, HIPAA, SOC 2, and other data protection frameworks by restricting who can access personal or confidential data.
- Data Integrity: Prevents unauthorized users from editing critical fields, maintaining the accuracy and reliability of your data.
- Cleaner User Experience: Users see only the fields they need, reducing cognitive clutter and improving productivity.
- Security Beyond the UI: Unlike page layouts, FLS restrictions apply even through the Salesforce API and third-party integrations.
Field Level Security vs. Page Layouts: What's the Difference?
This is one of the most common points of confusion for Salesforce admins, so let’s clear it up once and for all.
Page Layouts control field visibility on record detail and edit pages only. A hidden field on a page layout can still be accessed through reports, API calls, related lists, or formula fields.
Field Level Security controls field access across the entire Salesforce org — UI, reports, list views, related lists, API, and more. If FLS is set to hidden, the field is inaccessible everywhere.
Best Practice: Use both together — use page layouts for UI organization and FLS for true security enforcement.
Priority: FLS takes precedence. If FLS hides a field, the page layout setting is irrelevant — the field won’t appear regardless.
How Field Level Security Works in Salesforce
Field level security can be configured through two main mechanisms: Profiles and Permission Sets.
1. Profiles
Profiles define the baseline level of access for a group of users. Every user in Salesforce is assigned exactly one profile. When you configure FLS at the profile level, those settings apply to all users on that profile by default.
Profiles are ideal for setting the default, most restrictive level of access. You can define which fields are visible and which are editable for users on that profile.
2. Permission Sets
Permission sets allow admins to grant additional access to individual users without changing their profile. They work on top of profiles — you can use a permission set to expand access to specific fields for users who need it due to their unique responsibilities.
For example, your HR team may all share the same profile, but only your HR Director needs to see the Salary field. Instead of creating a separate profile, you create a permission set that grants Salary field visibility and assign it just to the HR Director.
Best Practice: Salesforce recommends moving toward a minimum access profile + permission sets model. Restrict access at the profile level and use permission sets to expand access as needed. This is more flexible and easier to manage as your org grows.
Types of Field Access in Salesforce
Visible (Edit Access): Users can view AND edit this field. The most permissive setting.
Read Only: Users can view the field value but cannot make changes to it.
Hidden (Not Visible): Users cannot see or interact with this field anywhere in the system — including reports, list views, and the API.
How to Set Field Level Security in Salesforce: Step-by-Step
There are three main ways to configure field level security in Salesforce.
Method 1: Set FLS Through a Profile
- Navigate to Setup by clicking the gear icon in the top-right corner.
- In the Quick Find search box, type Profiles and click on Profiles.
- Click the name of the profile you want to modify.
- Scroll down to the Field-Level Security section and click View next to the object containing the field you want to configure.
- Check or uncheck the Visible and Read-Only checkboxes for each field as needed.
- Click Save.
Method 2: Set FLS Through a Permission Set
- Navigate to Setup and search for Permission Sets in Quick Find.
- Click on the permission set you want to modify (or create a new one).
- Click Object Settings and select the object containing the field.
- Adjust the field-level access settings as required.
- Click Save, then assign the permission set to the relevant users.
Method 3: Set FLS During Field Creation
- When creating a new custom field in Object Manager, Step 3 of the field creation wizard is Establish field-level security.
- Set the visibility and edit access for each profile directly from this screen.
- Complete the remaining steps and save the field.
This method is highly recommended because it ensures FLS is properly configured from the moment a new field is created, rather than leaving it open by default.
Best Practices for Field Level Security in Salesforce
1. Apply the Principle of Least Privilege
Grant users the minimum access they need to perform their job. Start with the most restrictive settings and expand access only when there is a specific, documented business need.
2. Use a Minimum Access Profile + Permission Sets Model
Rather than creating many profiles with different levels of access, maintain fewer, more restrictive profiles and layer permission sets on top. This makes your security model more modular, transparent, and easier to audit.
3. Enable Field-Level Security for Permission Sets During Field Creation
In Salesforce’s User Management Settings, you can enable an option called Field-Level Security for Permission Sets during Field Creation. This ensures that when a new field is created, permission sets take priority — an important step toward a cleaner, more modern security model.
4. Conduct Regular Security Audits
FLS settings can drift over time, especially in fast-moving orgs where admins are frequently making changes. Schedule quarterly audits using the Field Accessibility viewer to catch misconfigurations before they become data breaches. Automate reports to flag changes to critical field permissions.
5. Combine FLS with Page Layouts Thoughtfully
FLS and page layouts serve different purposes. Use FLS to enforce true security restrictions, and use page layouts to organize the user experience. Never rely on page layouts alone for data security.
6. Enable Field History Tracking on Sensitive Fields
For fields that contain particularly sensitive or compliance-critical data, enable field history tracking. This creates an audit trail of changes — who changed a value, when, and what the previous value was — which is invaluable for regulatory compliance and incident investigations.
7. Use Validation Rules on Critical Fields
Pair FLS with validation rules on sensitive fields to enforce business logic and data accuracy. This adds an extra layer of protection, ensuring that even users who can edit a field must do so within defined rules.
Common Field Level Security Mistakes and How to Avoid Them
Over-relying on Page Layouts for security: Always configure FLS in profiles/permission sets. Page layouts are for UI experience, not data security.
Creating too many profiles: Use a minimum access profile + permission sets model. Fewer profiles = easier management.
Skipping FLS setup when creating new fields: Configure FLS in Step 3 of the field creation wizard so new fields are secure from day one.
Forgetting to enable FLS for permission sets: In User Management Settings, enable FLS for Permission Sets during Field Creation to ensure permission sets take priority.
Neglecting regular audits: Use the Field Accessibility viewer and schedule quarterly reviews to catch drift and misconfigurations.
Granting broad access just in case: Apply the principle of least privilege. Only grant access when there is a specific, documented business need.
Frequently Asked Questions: Field Level Security in Salesforce
Does FLS apply to API access?
Yes. Unlike page layout restrictions, field level security restrictions apply to all Salesforce access channels, including the REST API, SOAP API, and third-party integrations. If a field is hidden at the FLS level, it will not be accessible via the API either.
What happens if a user's profile and permission set have conflicting FLS settings?
Permission sets are additive — they can only expand access beyond what a profile allows, not reduce it. So if a profile grants read-only access to a field and a permission set grants edit access, the user will have edit access. The most permissive setting wins.
Can FLS be set for standard fields?
Yes, field level security can be configured for most standard Salesforce fields, not just custom fields. However, some system fields (like record ID or created date) cannot have their FLS modified.
Does FLS affect formula fields?
This is an important distinction. Page layouts do not protect formula fields — a user can still see a formula field’s output even if the underlying field is hidden on the page layout. However, if FLS hides the underlying field, users cannot see its value through formula fields either, providing true protection.
How does FLS interact with reports?
If a field is hidden via FLS for a user’s profile/permission set combination, that user will not be able to add that field to a report, and it will not appear in report results. This is another reason why FLS is far more secure than page layout restrictions.
Conclusion
Field level security in Salesforce is a foundational component of a robust data protection strategy. It goes beyond what page layouts can offer by securing field access across every touchpoint in your Salesforce environment — the UI, Reports, list views, related lists, and the API.
As a Salesforce admin, mastering FLS means you can confidently protect sensitive data, meet compliance requirements, and build a clean, role-appropriate user experience. The key is to combine profiles and permission sets intelligently, audit your settings regularly, and always apply the principle of least privilege.
Ready to level up? Start your Salesforce Admin certification journey today and build the skills that make you indispensable to any Salesforce org.
