3.3 Field-Level Security, Page Layouts, and Dynamic Forms

Field Security Is Not The Same As Page Design

Field-level security, usually called FLS, decides whether a user can see or edit a field. It is enforced broadly enough that users should not be able to bypass it just by switching from a record page to a report, list view, related list, search result, or API-based tool that respects their user permissions. For sensitive data such as salary, credit limit, government identifier, margin, discount approval, or health-related case details, start with FLS.

Page layouts decide how fields, buttons, related lists, and sections appear on a record page for a profile and record type. A layout can make a field read-only or hide it from that page. However, hiding a field on a page layout is not the same as securing it. If FLS says the field is visible, the user may still access it through reports, list views, search, or other interfaces.

Dynamic Forms And Component Visibility

Dynamic Forms lets admins place fields and field sections directly on Lightning record pages for supported objects and apply visibility rules. Component visibility can show or hide sections based on record fields, user attributes, form factor, permissions, or other supported conditions. This is powerful for reducing clutter and guiding users through a process.

Dynamic visibility is still not a security boundary. If a field is sensitive, configure FLS first. Then use Dynamic Forms to improve the experience for users who are allowed to see it. This order matters in real orgs and exam scenarios. A Lightning page that hides a salary field from contractors is not sufficient if contractor users still have field visibility and can report on the field.

Page layout assignment still matters. Record types can drive layout assignment and picklist values. A profile can have different layouts for different record types. Dynamic Forms may reduce dependence on giant layouts, but admins must still understand the layout and record type matrix because many standard and custom UI behaviors continue to use it.

Read-Only Can Come From Several Places

A field can be read-only because of FLS, page layout settings, field type, formula behavior, system ownership, approval lock, validation design, or automation. Formula fields are calculated and not directly editable. Roll-up summary fields are calculated. Created By and Last Modified Date are system fields. A field marked read-only on layout may be editable elsewhere if FLS and object permission allow it, depending on interface and operation.

When a user can see a field but cannot edit it, ask where the read-only state is enforced. Check object Edit, record edit access, FLS edit permission, page layout property, record type, field type, approval process locks, validation rules, and flows. Do not immediately grant Modify All Data. Broad permissions can mask the symptom while weakening the org.

Setup Paths And Admin Workflow

Common setup paths include Object Manager > Object > Fields & Relationships > Field > Set Field-Level Security, Object Manager > Object > Page Layouts, Object Manager > Object > Lightning Record Pages, and Object Manager > Object > Record Types. You can also inspect permission sets and profiles directly when checking field permissions.

Use this field troubleshooting workflow:

1. Identify the user population, object, record type, field, and interface.
2. Check object Read or Edit permission for the intended action.
3. Check FLS visible and read/edit settings from profiles and permission sets.
4. Check whether the field is on the assigned page layout or Dynamic Forms page.
5. Check component visibility filters and form factor behavior.
6. Check record type and picklist availability if the symptom involves choices.
7. Check automation, validation rules, duplicate rules, and approval locks if save fails.
8. Test as a representative non-admin user, not as a system administrator with broad access.

Scenario: Customer service agents cannot see a custom field named Escalation Risk on Case. The field is absent from the Lightning page and also unavailable in reports. That points to FLS first. Add visible access through the correct permission set, then place it on the Lightning page if needed. Adding the field only to the page will not help if FLS hides it.

Scenario: Sales reps can report on Margin Percent but it is not shown on their Opportunity page. Because they can report on it, FLS likely exposes the field. The fix may be page layout or Dynamic Forms, unless the business decides the field should be secured. The admin should confirm intent before exposing or hiding it.

Scenario: A field appears for one profile but not another on the same record type. Compare FLS, assigned layout, Lightning page activation, and permission set assignments. A record type mismatch can also present a different layout and picklist set.

Exam Traps

The most common trap is treating page layout as security. Page layout controls presentation. FLS controls whether the field is visible or editable for the user. Dynamic Forms controls page behavior. Record types shape business processes and picklist choices. These tools overlap on the screen, but they solve different problems.

Another trap is assuming System Administrator behavior proves the configuration works. Admins often have broad field and object access, so testing with an admin can hide security defects. Use a clean test user or Login-As workflow aligned with company policy. In study practice, create two users in a Trailhead Playground, give one the field permission and withhold it from the other, then compare record page and report behavior.