How to Set Field-Level Security in Salesforce

Field-level security (FLS) in Salesforce controls which fields a user can see and edit — independently of the page layout. It is a security boundary that Salesforce enforces across the UI, API, SOQL, reports, list views, and search, so a field locked down by FLS stays hidden everywhere, not just on one screen.

You can set FLS in three places: on the field itself in Object Manager, on a permission set (Salesforce's recommended approach), or on a profile. This guide walks through each path, explains how FLS differs from page-layout visibility, and shows how to respect FLS in Apex.

Key takeaways

• FLS is a security boundary, not a UI tweak. It governs read/edit access to a field everywhere Salesforce exposes data.
• Permission sets are the recommended path. Use profiles for a minimal baseline and permission sets (and permission set groups) for additive grants.
• Profiles still control FLS and are not being removed — manage them, but lean on permission sets to scale.
• Page layouts are not security. Hiding a field on a layout only hides it on that screen; the data is still reachable via the API, reports, and other layouts.
• Apex runs in system mode by default and ignores FLS unless you enforce it with WITH USER_MODE, Security.stripInaccessible(), or Schema describe checks.

What is field-level security in Salesforce?

Salesforce layers data access from broad to narrow:

• Object-level permissions decide whether a user can read, create, edit, or delete a type of record (for example, Accounts).
• Record-level sharing decides which records of that type a user can access.
• Field-level security decides which fields on those records a user can see or edit.

FLS is the most granular layer. If a Salary field on the Employee object should only be visible to HR, you remove read access for every other group at the field level — even if they can otherwise open the record.

FLS offers exactly two settings per field, per profile or permission set:

• Read access (Visible) — the user can see the field's value.
• Edit access — the user can change the field's value (requires read access too).

Remove both and the field disappears from the UI, API responses, reports, list views, and search results for that user.

FLS vs page-layout field visibility

The most common Salesforce mistake is treating a page layout like a security control. It is not. A field hidden or set to read-only on a layout is hidden on that layout only — the value is still returned by the API, reports, list views, and any other layout.

Aspect	Field-level security	Page-layout visibility
Purpose	Security boundary	UI arrangement
Where enforced	UI, API, SOQL, reports, list views, search	That one page layout only
Bypassable?	No — enforced everywhere	Yes — via API, reports, other layouts
Settings	Read, Edit	Visible, Read-only, Required
Use it to	Hide or lock sensitive data	Organize and de-clutter screens

Rule of thumb: if data must be protected, use FLS. If you only want to tidy a screen, use the layout. Note that a field marked Required on a layout but hidden by FLS will block record saves — so keep the two in sync.

Where can you set field-level security?

Method	Setup path	Best for
Object Manager (per field)	Object Manager → [Object] → Fields & Relationships → [field] → Set Field-Level Security	Setting one field across many profiles at once
Permission set (recommended)	Setup → Permission Sets → [set] → Object Settings → [object] → Field Permissions	Additive, reusable grants you assign to many users
Profile	Setup → Profiles → [profile] → Object Settings / Field-Level Security	Baseline access for a category of user

Method 1: Set FLS on the field (Object Manager)

This is the fastest way to set one field across many profiles at once.

1. From Setup, open Object Manager and select the object.
2. Click Fields & Relationships, then open the field.
3. Click Set Field-Level Security.
4. For each profile, tick Visible and/or Read-Only, then click Save.

Method 2: Set FLS with a permission set (recommended)

Permission sets grant access on top of a profile, so you can give a few users extra field access without cloning a whole profile.

1. From Setup, go to Permission Sets and open (or create) a set.
2. Under Apps, click Object Settings and choose the object.
3. Click Edit, then set Read Access / Edit Access per field under Field Permissions, and Save.
4. Assign the permission set to users via Manage Assignments.

Method 3: Set FLS on a profile

1. From Setup, go to Profiles and open the profile.
2. In the enhanced profile UI, open Object Settings → the object (or use Field-Level Security in the original profile UI).
3. Click Edit, set Read Access / Edit Access per field, and Save.

Profiles or permission sets: which should you use?

Salesforce's guidance is to use profiles for a minimal baseline and permission sets (and permission set groups) for everything additive. Permission sets scale better: one set can be assigned to thousands of users across different profiles, so you stop cloning near-identical profiles every time a team needs one extra field.

A note on the rumors: Salesforce once signaled it would retire profile-based permissions, then walked back that hard end-of-life. The accurate position today is that permission sets are the recommended path, but profiles still control field-level security and are not being removed. Build new, additive access with permission sets — you don't need to panic-migrate existing profiles.

For a step-by-step walkthrough, see our guide on creating and assigning Salesforce permission sets.

Does Apex respect field-level security?

Not automatically. Apex runs in system mode by default, which bypasses FLS and object permissions. If you query or write fields in Apex without enforcing security, you can expose data a user shouldn't see. There are three main ways to enforce FLS in code:

• WITH USER_MODE (or the older WITH SECURITY_ENFORCED) in SOQL — throws an exception if the running user lacks field or object access.
• Security.stripInaccessible() — strips fields the user can't access from query results or DML input instead of throwing.
• Schema.DescribeFieldResult.isAccessible() / isUpdateable() — check access manually before reading or writing a field.

// 1) Enforce FLS + object permissions directly in the query (throws if inaccessible)
List<Contact> contacts = [
    SELECT Id, Name, Email, SSN__c
    FROM Contact
    WHERE CreatedDate = LAST_N_DAYS:30
    WITH USER_MODE
];

// 2) Strip fields the running user cannot read — no exception thrown
SObjectAccessDecision decision = Security.stripInaccessible(
    AccessType.READABLE,
    [SELECT Id, Name, SSN__c FROM Contact]
);
List<Contact> safe = (List<Contact>) decision.getRecords();

// 3) Check a specific field before using it
if (Schema.sObjectType.Contact.fields.SSN__c.isAccessible()) {
    // safe to read Contact.SSN__c
}
if (Schema.sObjectType.Contact.fields.SSN__c.isUpdateable()) {
    // safe to write Contact.SSN__c
}

Field-level security best practices

• Audit before you hide. Use Setup → Security → Field Accessibility, pick an object, and view by field or by profile to see who can read or edit each field.
• Lock down sensitive fields by default, then grant access with permission sets — easier to reason about than removing access later.
• Keep layouts and FLS consistent. A field marked Required on a layout but hidden by FLS will block saves.
• Enforce FLS in code. Add WITH USER_MODE or stripInaccessible() to custom Apex; standard Lightning data services honor FLS automatically, but your own queries do not.
• Test as the user. Use Login As to confirm a profile truly can't see a restricted field across the UI, reports, and API.

For broader configuration guidance, see our Salesforce customization best practices. If you'd like hands-on help hardening your org, explore our Salesforce consulting services.

Frequently Asked Questions

What is field-level security in Salesforce?

Field-level security (FLS) controls which fields a user can view and edit on a record, independently of the page layout. It is enforced across the UI, API, SOQL, reports, list views, and search, which makes it a true security boundary rather than a display setting.

What is the difference between field-level security and page layouts?

FLS is a security control enforced everywhere Salesforce exposes data, so a field hidden by FLS is hidden in the API, reports, and every layout. A page layout only controls how fields appear on one screen — hiding a field there does not stop it being read via the API or reports.

Should I set field-level security on profiles or permission sets?

Salesforce recommends using profiles for a minimal baseline and permission sets (and permission set groups) for additive grants. Permission sets scale better because one set can be assigned to many users across different profiles, so you avoid cloning near-identical profiles.

Are Salesforce profiles being removed?

No. Salesforce once signaled it might retire profile-based permissions but walked back that hard end-of-life. Profiles still control field-level security and are not being removed; permission sets are simply the recommended path for new, additive access.

Does Apex enforce field-level security automatically?

No. Apex runs in system mode by default and bypasses FLS. You must enforce it explicitly using WITH USER_MODE or WITH SECURITY_ENFORCED in SOQL, Security.stripInaccessible(), or Schema describe checks such as isAccessible() and isUpdateable().

How do I quickly check which fields a profile can access?

Use Setup → Security → Field Accessibility, pick an object, and view by field or by profile. It shows whether each field is hidden, read-only, or editable for each profile, which is useful for auditing FLS before and after changes.