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

Salesforce Admin Study Guide Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Platform Administrator Orientation and Official Source Control

1.1 Credential Name, Current Outline, and Search Language 1.2 Exam Format, Fee, Score, and Reference Rules 1.3 Trailhead, Trailhead Academy, and Pearson VUE Delivery Workflow 1.4 Domain Weights, Agentforce, and Study Prioritization 1.5 Maintenance Modules, Credential Ethics, and Exam Security 1.6 Developer Edition, Trailhead Playground, and Practice Bank Workflow

2 Chapter 2: Configuration, Setup, User Management, and Org Controls

2.1 Company Information, Fiscal Year, Business Hours, and Locale 2.2 User Records, Licenses, Profiles, Permission Sets, and Login Access 2.3 Login Security, Session Settings, and Identity Basics 2.4 Setup Navigation, Release Readiness, and Change Control 2.5 UI Settings, Home Pages, Apps, and Navigation 2.6 Configuration and Setup Case Lab

3 Chapter 3: Security, Access, Identity, and Sharing Model

3.1 Org-Wide Defaults, Roles, Sharing Rules, and Teams 3.2 Profiles, Permission Sets, Permission Set Groups, and Muting 3.3 Field-Level Security, Page Layouts, and Dynamic Forms 3.4 Record Access Troubleshooting and Login-As Workflow 3.5 Identity, Login History, MFA, and Session Risk 3.6 Data Visibility, Reporting, and Analytics Security 3.7 Security and Access Case Lab

4 Chapter 4: Object Manager, Lightning App Builder, and Data Modeling

4.1 Standard Objects, Custom Objects, and Schema Fit 4.2 Fields, Formulas, Rollups, Validation, and Requiredness 4.3 Lookup, Master-Detail, and Junction Relationships 4.4 Record Types, Business Processes, Page Layouts, and Lightning Pages 4.5 Dynamic Forms, Dynamic Actions, and User Experience 4.6 Schema Change Risk, Data Quality, and Deployment Readiness 4.7 Object Modeling Case Lab

5 Chapter 5: Sales, Marketing, Service, and Support Applications

5.1 Lead, Campaign, Account, Contact, and Opportunity Flow 5.2 Sales Processes, Path, Products, Price Books, and Forecasting 5.3 Case Management, Queues, Assignment, Auto-Response, and Escalation 5.4 Knowledge, Entitlements, Service Console, and Support Productivity 5.5 Sales-Service Data Quality and Automation Boundaries 5.6 Application Configuration Troubleshooting 5.7 Sales and Service Applications Case Lab

6 Chapter 6: Data and Analytics Management

6.1 Data Import Wizard, Data Loader, Export, and Backup 6.2 Duplicate Management, Validation, and Data Quality Controls 6.3 Data Transfer, Ownership, Mass Update, and Mass Delete 6.4 Report Types, Filters, Summary Formulas, and Buckets 6.5 Dashboards, Components, Subscriptions, and Sharing Impact 6.6 Analytics Security, Visibility, and Executive Reporting 6.7 Data and Analytics Case Lab

7 Chapter 7: Automation, Flow, Approval, and Operational Processes

7.1 Automation Tool Selection and Order of Execution 7.2 Flow Builder: Screen, Record-Triggered, Scheduled, and Autolaunched Flows 7.3 Approval Processes, Email Alerts, and Notification Patterns 7.4 Validation Rules, Assignment Rules, and Escalation Rules 7.5 Automation Testing, Debugging, and Governance 7.6 Automation Performance, Recursion, and Maintainability 7.7 Automation Case Lab

8 Chapter 8: Productivity, Collaboration, Mobile, and AppExchange

8.1 Activities, Tasks, Events, Calendar, and Email Productivity 8.2 Chatter, Feeds, Groups, Notifications, and Collaboration Governance 8.3 Salesforce Mobile Navigation, Actions, and Page Design 8.4 List Views, Kanban, Path, and User Adoption Tools 8.5 AppExchange Evaluation, Installation, Permissions, and Risk 8.6 Productivity and Collaboration Case Lab

9 Chapter 9: Agentforce for Platform Administrators

9.1 Agentforce Use Cases, Admin Boundaries, and Fit 9.2 Trusted AI, Security, Data Access, and Permission Implications 9.3 Agent Builder, Prompt Builder, and Grounding Concepts 9.4 Testing, Deployment, Monitoring, and Feedback Workflows 9.5 Agentforce Service, Sales, and Internal Productivity Scenarios 9.6 Agentforce Risk, Troubleshooting, and Governance 9.7 Agentforce Case Lab

10 Chapter 10: Integrated Salesforce Admin Scenario Labs

10.1 New Sales Org Setup Integrated Lab 10.2 Service Team Case Management Integrated Lab 10.3 Data Quality and Analytics Integrated Lab 10.4 Security, Access, and Reporting Integrated Lab 10.5 Flow Automation and Change Control Integrated Lab 10.6 Agentforce and Adoption Integrated Lab 10.7 Full Admin Simulation Strategy

11 Chapter 11: Final Review, Maintenance, and Test-Day Strategy

11.1 Final 30-Day Salesforce Admin Review Plan 11.2 Trailhead Playground Hands-On Drill Plan 11.3 105-Minute Exam Timing, Flagging, and Review Workflow 11.4 Test-Day Checklist: Online or Test Center 11.5 Post-Exam Maintenance Modules and Next Certifications 11.6 Salesforce Admin Final Mixed Review

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

Key Takeaways Explain This Topic AI

Field-level security is a security control that applies beyond the record page, including reports, list views, search, APIs, and automation contexts where user visibility matters.

Page layouts control record page presentation and editability in the classic layout layer, but they do not secure a field that field-level security exposes.

Dynamic Forms and component visibility improve Lightning page relevance, but visibility rules are not a substitute for field-level security.

Field troubleshooting should identify whether the symptom is hidden, read-only, absent from layout, unavailable by record type, blocked by validation, or changed by automation.

Last updated: May 2026

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.

Requirement Primary tool Why

Hide a confidential field everywhere from a group of users. Field-level security. Security must apply beyond one page.

Put sales fields in a better order for one profile. Page layout or Dynamic Forms. This is presentation, not security.

Show a Lightning field section only when Stage equals Closed Lost. Dynamic Forms visibility. The condition improves page relevance.

Make a field read-only on one layout while still reportable. Page layout read-only. UI edit control is enough when security allows visibility.

Limit picklist values by business process. Record type and picklist settings. Picklist availability is not the same as FLS.

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:

Identify the user population, object, record type, field, and interface.

Check object Read or Edit permission for the intended action.

Check FLS visible and read/edit settings from profiles and permission sets.

Check whether the field is on the assigned page layout or Dynamic Forms page.

Check component visibility filters and form factor behavior.

Check record type and picklist availability if the symptom involves choices.

Check automation, validation rules, duplicate rules, and approval locks if save fails.

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.