Field-Level Security Across Profiles and Permission Sets

Why Field-Level Security Matters

Field-Level Security (FLS) is one of the three pillars of the Salesforce security model, sitting between object-level permissions (can the user see or work with this type of record at all?) and record-level sharing (which specific records can the user see?). FLS answers a narrower but critical question: of the records a user can access, which individual fields can they view, and which can they edit?

It matters for three reasons. First, compliance and privacy: salary, Social Security numbers, health information, credit limits, and internal margin data must be hidden from users who have no business need to see them, even when those users legitimately own or work the record. Second, data integrity: fields such as approval status, pricing tiers, or system-calculated values should be visible to many but editable by few. Third, the Advanced Administrator exam itself: the Security and Access domain is heavily weighted, and FLS questions appear frequently, usually disguised as troubleshooting scenarios ("a user cannot see a field in a report") or design scenarios ("a subset of users in one profile needs edit access to a field without impacting others"). You are expected to understand not only how to set FLS, but how it interacts with page layouts, permission sets, permission set groups, reports, list views, the API, and the additive nature of Salesforce permissions.

What Field-Level Security Is

FLS is a set of permissions defined on each field of an object that control two things for a given profile or permission set:

- Read Access (labeled Visible in the Profile interface): whether the user can see the field at all.
- Edit Access (the absence of Read-Only in the Profile interface): whether the user can change the field's value.

A field can therefore be in one of three states for a user: hidden, read-only, or editable. These settings are enforced everywhere the platform surfaces data: record detail and edit pages, Lightning record pages and Dynamic Forms, related lists, list views, reports and dashboards, search results, the Salesforce mobile app, Data Loader, the SOAP and REST APIs, Flow screens, Experience Cloud sites, and Visualforce pages that use standard controllers. This universality is the key difference between FLS and page layouts, which only affect the user interface.

One important nuance: Apex code runs in system mode by default and does not automatically enforce FLS. Developers must explicitly enforce it using constructs such as WITH SECURITY_ENFORCED, WITH USER_MODE, or Security.stripInaccessible(). The exam may test whether you know that custom Apex can expose fields that FLS hides unless the developer has taken steps to respect it.

How It Works: Profiles

Every user has exactly one profile. The profile establishes a baseline for FLS on every field of every object. When an administrator creates a new custom field through the field creation wizard, Step 2 (Establish field-level security) lets the admin choose which profiles can see the field and which see it as read-only. By default, standard profiles like System Administrator are granted visible access and other profiles vary; the admin should always review this step rather than accept defaults.

To edit FLS on an existing field you have two paths:

- From the object: Setup > Object Manager > [Object] > Fields and Relationships > [Field] > Set Field-Level Security. This shows one field across all profiles, which is ideal when you have just created or modified a single field.
- From the profile: Setup > Profiles > [Profile] > Object Settings > [Object] > Field Permissions. This shows all fields for one object within one profile, which is ideal when onboarding a new role.

Note that you can edit FLS on standard profiles, even though you cannot edit their object permissions, user permissions, or app permissions. This is a frequent exam distinction.

Because Salesforce is moving toward a minimum access profile plus permission sets model, the exam increasingly favors answers where the profile grants very little and permission sets layer on access. A newer User Management setting, Field-Level Security for Permission Sets during Field Creation, allows the field wizard to assign FLS to permission sets instead of profiles, reflecting this shift.

How It Works: Permission Sets

A permission set is a reusable collection of settings and permissions that can be assigned to any number of users regardless of profile. Permission sets contain the same FLS structure as profiles (Read Access and Edit Access per field). A user can hold many permission sets simultaneously.

The defining rule is that permissions in Salesforce are additive. A user's effective access to a field is the union of what the profile grants plus what every assigned permission set grants. If the profile hides a field but one permission set grants Read, the user can read the field. If the profile grants Read and a permission set grants Edit, the user can edit. Critically, a permission set can never remove or restrict access that the profile or another permission set already grants. There is no concept of a negative permission set. If a scenario asks how to take away access from some users within a profile, the answer is to remove the access from the profile (or move it out of the profile) and grant it back through a permission set only to those who still need it.

Permission sets can also be assigned with an expiration date, and session-based permission sets can grant field access only while a verified session is active, which is useful for high-sensitivity fields.

How It Works: Permission Set Groups and Muting

Permission set groups bundle multiple permission sets so they can be assigned as a single unit representing a job function or persona. The group's effective permissions are the combination of all included sets. Within a group, a muting permission set can be added to disable specific permissions, including field Read or Edit, for everyone assigned that group. Muting is the only way to subtract permissions, and it operates only within the group; it does not affect access granted by the user's profile or by permission sets assigned outside the group. Exam scenarios that say "use an existing bundle of permission sets but prevent one field from being editable" are pointing to a muting permission set.

How It Works: Interaction with Object Permissions

FLS does nothing on its own if the user lacks object permissions. To view a field, the user needs object Read plus field Read. To edit a field, the user needs object Edit, field Edit, and the record itself must be editable under sharing rules. The three layers must all permit the action. "View All Data" and "Modify All Data" override record-level sharing but do not override FLS; a user with Modify All Data still cannot see a field hidden by FLS.

How It Works: Interaction with Page Layouts and Dynamic Forms

Page layouts (and field sections in Dynamic Forms) also control whether a field appears on the record page and whether it is read-only or required. The relationship follows a most restrictive wins rule in the user interface:

- If FLS hides a field, it will not appear on any page layout, regardless of layout settings. FLS cannot be overridden by a page layout.
- If FLS makes a field read-only, the page layout cannot make it editable.
- If FLS makes a field editable but the page layout marks it read-only, the user sees it as read-only on that layout, but can still edit it through the API, Data Loader, list view inline editing in some cases, or a different page layout assigned via record type.
- A field marked Required on a page layout is required only in that user interface context. To enforce a requirement everywhere, use a validation rule or make the field universally required at the field definition level.

The Setup tool Field Accessibility (Setup > Security > Field Accessibility) is the definitive place to see the combined result of FLS and page layout for a given object, field, profile, and record type. It displays each field as Hidden, Read-Only, Editable, or Required and lets you click through to fix either layer. On the exam, when a question asks which tool shows the effective visibility of a field for a profile considering both FLS and layout, Field Accessibility is the answer. For an individual user's effective permissions across profile and all permission sets, the User Access Summary on the user record is the modern answer.

Special Field Behaviors

- Universally required fields: automatically visible and editable in FLS for all profiles; you cannot hide them or make them read-only through FLS.
- Formula, roll-up summary, auto-number, and system fields (Created By, Last Modified Date, etc.): always read-only; FLS can only control visibility.
- Master-detail relationship fields: required by nature, so they follow universally required behavior.
- Classic encrypted fields: viewing the unmasked value requires the View Encrypted Data permission in addition to field Read. Shield Platform Encryption, by contrast, does not use a separate view permission and relies on standard FLS.
- Record type picklist values are controlled by record types, not FLS; FLS controls the field, record types control which values appear.
- Field history tracking: users can see history entries only for fields they have Read access to.
- Reports: fields hidden by FLS do not appear in the report builder, in results, or as exportable columns. If a report type includes a field the user cannot see, it is silently omitted for that user.
- List views: hidden fields are not available as columns or filters for that user; if a saved list view includes a hidden column, that column does not render for the user.

Common Design Patterns the Exam Expects

1. A subset of users sharing a profile needs edit access to a field: Leave the profile as-is (or restrict it) and create a permission set granting Edit on the field, assigned only to those users.

2. Several job functions each need a bundle of access, and one function must be prevented from editing one field: Build permission set groups per function; add a muting permission set to the relevant group.

3. A field must be read-only for most users but editable by managers: Profile grants Read only; permission set grants Edit to managers.

4. A field should be hidden from sales reps but visible to finance: Set FLS to hidden on the sales profile (or remove it from the minimum access profile) and grant Read via a Finance permission set. Do not use page layouts, because reps could still see the field in reports and via the API.

5. A field is visible in the UI but a user cannot find it in reports: This cannot be an FLS issue if the field truly appears on the record page, so check the report type and report-type field selection. Conversely, if a field appears in reports but not on the page, the issue is the page layout or record type assignment, not FLS.

6. Users must be forced to populate a field: Page layout required works only in the UI; a validation rule or universally required setting works everywhere including Data Loader.

Exam Tips: Answering Questions on Field-Level Security Across Profiles and Permission Sets

Tip 1: Identify which security layer the question is really about. If the problem concerns which records a user sees, it is sharing (OWD, roles, sharing rules, teams), not FLS. If it concerns whether the user can see the object or tab at all, it is object permissions or tab settings. If it concerns a specific field, it is FLS or page layout. Eliminate answer choices that address the wrong layer immediately.

Tip 2: Decide between FLS and page layout using the "everywhere" test. Ask whether the symptom or requirement spans reports, list views, the API, or mobile. If yes, the answer involves FLS. If the issue is confined to one record page or one record type, think page layout or Dynamic Forms visibility. If a field is visible in a report but missing from the record page, it is a page layout problem. If a field is missing from both, it is FLS.

Tip 3: Remember that permissions are additive and permission sets only grant. Any answer that proposes using a permission set to remove or restrict access is wrong unless the question explicitly involves a muting permission set inside a permission set group. When the scenario requires taking access away from some but not all users of a profile, the correct pattern is to remove it from the profile and restore it with a permission set.

Tip 4: Prefer permission sets over profile changes or new profiles. Salesforce exam answers consistently favor minimizing profile proliferation. Phrases such as "without creating a new profile," "a subset of users," "some users across multiple profiles," or "least privilege" signal that a permission set or permission set group is the intended answer.

Tip 5: Know the three required ingredients for editing a field. Object Edit, field Edit, and record-level edit access via sharing or ownership. A troubleshooting question in which a user can see a field but cannot change it may be caused by any one of these, or by a page layout set to read-only. Check what the question tells you about reports and API to narrow it down.

Tip 6: Know what overrides and what does not. View All Data and Modify All Data do not bypass FLS. Page layouts cannot override FLS. FLS cannot hide universally required fields. Formula and system fields are always read-only. Apex runs in system mode and ignores FLS unless the developer enforces it.

Tip 7: Match the tool to the diagnostic question. "See one field across all profiles" = Set Field-Level Security from the field. "See all fields for one profile" = Profile > Object Settings. "See the combined effect of FLS and page layout by profile and record type" = Field Accessibility. "See everything one specific user can do, across profile and permission sets" = User Access Summary (or the user record's permission set assignments). "Find which permission sets grant a field" = Object Manager field page, Set Field-Level Security view showing permission sets, or permission set field permissions.

Tip 8: Watch for required-field traps. "Required on the page layout" enforces only through the UI. "Universally required" and validation rules enforce everywhere including integrations and Data Loader, and universally required fields automatically become visible and editable for all profiles in FLS.

Tip 9: Read for the number of users and personas. One-off access for a few people = permission set. Standardized bundles per job function = permission set group. Removing one piece from a standardized bundle = muting permission set. Temporary access = permission set with expiration date. Access only during verified sessions = session-based permission set.

Tip 10: When two answers both seem technically possible, choose the one that is most maintainable and follows Salesforce best practice. The exam rewards solutions that scale: granular permission sets, minimal profile changes, FLS for true data security, and page layouts only for presentation and UI-level convenience.

Summary

Field-Level Security determines whether a user can see or edit a specific field and is enforced across the entire platform, not just the UI. Profiles set the baseline, permission sets add access, permission set groups bundle it, and muting permission sets are the sole mechanism for subtracting within a bundle. FLS always wins over page layouts, cannot be bypassed by View All or Modify All Data, and does not apply to universally required fields. On the exam, success comes from correctly identifying the security layer in play, applying the additive model, distinguishing FLS from page layout behavior using the "everywhere" test, and choosing the scalable permission set approach whenever a subset of users needs different field access.