Study guide
9.1 Dynamic Forms & Conditional Component Visibility
Salesforce Certified Platform App Builder Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Platform Architecture, Boundaries & Extensions
1.1 Declarative vs. Programmatic Architecture & Limits 1.2 AppExchange Solutions & Package Selection 1.3 Core CRM Standard Objects & Capabilities
2 Chapter 2: Security, Access & Analytics
2.1 Object-Level & Field-Level Security 2.2 Record-Level Sharing Architecture 2.3 Advanced Sharing & Scoping Solutions 2.4 Reports, Custom Report Types & Dynamic Dashboards
3 Chapter 3: Data Model Architecture & Relationships
3.1 Custom Objects & Custom Field Types 3.2 Master-Detail & Lookup Relationships 3.3 Many-to-Many Relationships & Junction Objects 3.4 Schema Builder & Data Architecture Visualization
4 Chapter 4: Data Management & External Integrations
4.1 Field Type Conversions & Data Loss Considerations 4.2 Data Import Wizard vs. Data Loader 4.3 Salesforce Connect, External Objects & Indirect Lookups
5 Chapter 5: Declarative Formulas & Validation Rules
5.1 Cross-Object Formulas & Advanced Formula Functions 5.2 Roll-Up Summary Fields & Calculation Rules 5.3 Validation Rules & Error Handling Strategies
6 Chapter 6: Salesforce Flow Architecture & Design
6.1 Flow Fundamentals & Flow Trigger Types 6.2 Record-Triggered Flows: Fast Field Updates vs. Actions 6.3 Screen Flows & Guided User Interactions 6.4 Flow Execution Architecture, Bulkification & Fault Paths
7 Chapter 7: Complex Automation & Approval Processes
7.1 Multi-Step Approval Processes & Approver Routing 7.2 Approval Actions, Rejections & Record Locking 7.3 Automation Selection Strategy & Legacy Migration Patterns
8 Chapter 8: Lightning App Builder & Page Customization
8.1 Lightning Record, Home & App Pages 8.2 Standard, Custom & AppExchange Lightning Components 8.3 Custom Buttons, Web Links & Quick Actions
9 Chapter 9: Dynamic UI, Record Types & Mobile Experience
9.1 Dynamic Forms & Conditional Component Visibility 9.2 Dynamic Actions & Page Interaction Patterns 9.3 Record Types, Business Processes & Picklist Control 9.4 Salesforce Mobile App Customization & Compact Layouts
10 Chapter 10: Application Lifecycle Management & Sandboxes
10.1 Application Lifecycle Management (ALM) Stages & Governance 10.2 Sandbox Types, Capacity & Refresh Cycles 10.3 Sandbox Strategy for Development, Testing & Training
11 Chapter 11: Deployment Tools & Packaging Strategies
11.1 Inbound & Outbound Change Sets 11.2 Change Set Dependency Tracking & Deployment Sequencing 11.3 Managed vs. Unmanaged Packages & Distribution
12 Current Exam Blueprint, Agentforce & Flow Operations
12.1 Current Exam Facts, Official Weights & Study Mapping 12.2 AgentExchange: Extending an Org with the Agentforce Marketplace 12.3 Agentforce Automation for App Builders 12.4 Flow Approval Processes, Monitoring & Troubleshooting
9.1 Dynamic Forms & Conditional Component Visibility
Key Takeaways Explain This Topic AI
Dynamic Forms decouples record page layout design from legacy monolithic Page Layouts, allowing administrators to place individual fields and Field Sections anywhere on a Lightning record page.
Conditional visibility filters can be evaluated dynamically on individual fields, Field Sections, standard components, and custom Lightning Web Components using record field values, user attributes ( $User ), custom permissions ( $Permission ), and client device form factor.
Dynamic Forms improves page rendering performance and eliminates page layout sprawl by replacing dozens of near-identical page layouts with a single, dynamically adapting Lightning record page.
UI-level field properties configured in Lightning App Builder (Required or Read-Only) govern user interaction on that specific page but do not supersede Field-Level Security or database-level field requirements.
Dynamic Forms for Mobile extends dynamic field rendering and conditional visibility to the Salesforce Mobile App, activated via Salesforce Mobile App settings in Setup.
Last updated: October 2026
9.1 Dynamic Forms & Conditional Component Visibility
For years, Salesforce record user interfaces relied entirely on traditional Page Layouts configured in Object Manager. In this legacy paradigm, fields were bound to a monolithic Record Detail component on the Lightning page. If different departments, user roles, or lifecycle stages required different field layouts, administrators were forced to create dozens of distinct Page Layouts, pair them with separate Record Types, and assign them across complex profile matrices. This architectural constraint led to severe metadata sprawl, rigid page structures, and degraded page load performance.
Dynamic Forms fundamentally transforms this paradigm. It decomposes the rigid Record Detail component into atomic, individual fields and flexible Field Section components directly within Lightning App Builder. App Builders can place fields anywhere on a Lightning record page, organize them into multi-tab or accordion layouts, and apply granular conditional visibility rules to show only the data relevant to the current user, record status, and device.
The Dynamic Forms Architecture
Dynamic Forms shifts field management from Setup's legacy Page Layout editor directly into the modern Lightning App Builder . When Dynamic Forms is enabled on a record page:
The Fields Tab in Component Palette : A dedicated Fields tab appears on the left panel of Lightning App Builder, displaying all available standard and custom fields for the object, alongside a Field Section component.
Field Sections : Administrators drag a Field Section component onto any page region. A Field Section can be configured as a 1-Column or 2-Column layout, given a custom section label, and toggled as collapsible.
Individual Field Components : Rather than rendering all fields at once, individual fields are dragged directly into Field Sections. Fields can be reordered freely without opening Object Manager.
Flexible Page Placement : Because fields are now independent Lightning components, Field Sections can be embedded inside sub-tabs (e.g., a "Financial Details" tab), inside Accordion sections, or adjacent to custom Lightning Web Components (LWCs). [Legacy Page Layout Architecture]
- Lightning Record Page
- └── Record Detail Component (Monolithic Blob: 80+ Fields Loaded Simultaneously)
- [Dynamic Forms Architecture]
- Lightning Record Page
- ├── Tab: Overview
- │ └── Field Section: General Info (1-Column, 4 Fields)
- ├── Tab: Financials (Lazy Loaded)
- │ └── Field Section: Revenue Metrics (2-Column, 6 Fields with Visibility Rules)
- └── Tab: Compliance (Conditionally Rendered)
- └── Field Section: Audit Verification (2-Column, Restricted Fields)
- Upgrading Existing Pages to Dynamic Forms
App Builders do not need to rebuild existing record pages from scratch. Salesforce provides the Upgrade to Dynamic Forms migration assistant:
Open an existing Lightning record page in Lightning App Builder.
Click on the legacy Record Detail component.
In the component properties pane on the right, click the Upgrade Now button.
The migration wizard prompts the administrator to select an existing Page Layout to use as the source template.
The wizard automatically converts the fields and sections from that Page Layout into Dynamic Forms Field Section and Field components, preserving the existing order and column configurations.
After migration, the legacy Record Detail component is removed, and administrators can immediately configure conditional visibility rules or rearrange fields across tabs.
Note
Standard Object Support: Dynamic Forms is supported on most standard objects (including Account, Contact, Lead, Opportunity, Case, and supported LWC-enabled objects) as well as all custom objects. If an object does not yet support Dynamic Forms, the Fields tab will not appear in Lightning App Builder, and the Record Detail component cannot be upgraded.
Architectural Benefits: Performance & Sprawl Reduction
Dynamic Forms delivers two profound architectural advantages for enterprise Salesforce implementations:
1. Significant Page Load Time Reductions
Legacy Record Detail components execute a synchronous metadata payload call that retrieves and renders every single field, section, and related element defined on the underlying page layout at once. On records with 100+ fields, this creates massive Document Object Model (DOM) trees and high client-side CPU processing times.
With Dynamic Forms, fields placed within secondary tabs or closed accordion sections benefit from lazy loading . Inactive tabs can defer component loading; do not assume that every field below the visible viewport is unloaded. Secondary sections are loaded on demand when the user clicks the corresponding tab, dramatically cutting initial page load times (Experienced Page Time - EPT).
2. Elimination of Page Layout Sprawl
Consider a global enterprise where Sales, Operations, and Compliance teams each require distinct fields on the Opportunity object across 4 sales regions. Historically, this required: 3 Roles × 4 Regions = 12 Page Layouts + 12 Record Types \text{3 Roles} \times \text{4 Regions} = 12 \text{ Page Layouts} + 12 \text{ Record Types} 3 Roles × 4 Regions = 12 Page Layouts + 12 Record Types
With Dynamic Forms, the organization requires only one single Lightning record page . Field Sections and individual fields are displayed conditionally based on user role, region, and opportunity stage. Administrators maintain one master metadata canvas rather than dozens of duplicated layouts.
Field-Level UI Properties in Lightning App Builder
When an individual field is selected in Lightning App Builder, the properties panel allows administrators to set its UI behavior:
None (Standard) : The field adopts its default behavior based on Field-Level Security and the database schema.
Read-Only : The field is rendered as non-editable on this specific Lightning page. Users can view the value but cannot edit it via inline editing on this form.
Required : The field is marked with a red asterisk and must contain a value before the user can save the record on this form.
Important
UI Configuration vs. Database Integrity: Marking a field "Required" or "Read-Only" in Lightning App Builder applies only to that specific Lightning page . It does not enforce validation in the API, Data Loader, Background Flows, or other Lightning pages. Conversely, if a field is required at the database/schema level (configured on the custom field definition in Object Manager), Lightning App Builder automatically enforces it as Required and cannot make it optional.
Conditional Visibility Rules
Conditional visibility allows App Builders to dynamically display or hide components—including individual fields, Field Sections, standard components, and custom LWCs—based on runtime evaluations.
Visibility Filter Criteria Types
Administrators can configure filters using three primary data contexts:
Record Field : Evaluates field values on the current record or traversing lookup relationships up to 5 levels away (e.g., Status = 'Escalated' , or Account.Industry = 'Healthcare' ).
Device Form Factor : Evaluates the client hardware: Desktop vs. Phone . This enables presenting rich, dense field grids on desktop while displaying only critical fields on mobile devices.
Advanced (Global Variables) :
User Attributes ( $User ) : Evaluates fields on the running user's record, such as $User.Department = 'Compliance' , $User.City , or $User.Profile.Name = 'Custom: Sales' .
Custom Permissions ( $Permission ) : Evaluates whether the current user is assigned a specific Custom Permission via a Permission Set (e.g., $Permission.Can_Approve_Discounts = TRUE ).
Client Context ( $Client ) : Evaluates runtime client attributes such as $Client.formFactor .
Advanced Boolean Logic
Multiple filter lines can be combined using boolean operators: AND , OR , and custom filter logic (e.g., (1 AND 2) OR 3 ). If a Field Section is hidden by a visibility rule, all fields nested within that section are automatically hidden without needing individual field filters.
Dynamic Forms vs. Traditional Page Layouts
- Architectural Dimension Traditional Page Layouts Dynamic Forms in Lightning App Builder
- Configuration Location Setup > Object Manager > Page Layouts Setup > Lightning App Builder
- Field Granularity Monolithic block (all fields bound together) Atomic fields and modular Field Sections
Conditional Visibility Not supported (all layout fields render) Supported on Field Sections and individual fields
Visibility Criteria Static assignment by Profile & Record Type Dynamic by Record Fields, $User , $Permission , Device
- Page Performance Slower; loads entire metadata layout at once Faster; lazy-loads inactive tabs and accordions
- Required / Read-Only Configured statically in layout editor Configured per field instance in App Builder
- Mobile Support Rendered via Mobile & Lightning layout Enabled via "Dynamic Forms on Mobile" toggle
- Exam Traps and Architectural Best Practices
Trap: Relying on Dynamic Forms for Data Security. Hiding a field using a conditional visibility rule is a presentation convenience, not a security boundary . Users can still query hidden fields via reports, list views, Developer Console, REST/SOAP APIs, and Data Loader. To truly secure sensitive data, always enforce Field-Level Security (FLS) .
Trap: Confusing page-required and universally required fields. A field made Required only in App Builder does not block saving while hidden by a visibility rule. A universally required field in Object Manager still requires a value when hidden or omitted. Use a validation rule for conditional requirements that must also apply through APIs.
Best Practice: Use Custom Permissions Instead of Profile Names. In visibility filters, never hardcode $User.Profile.Name = 'Sales Manager' . Profiles change, get renamed, or are consolidated. Instead, create a Custom Permission (e.g., View_Executive_Metrics ), assign it to a Permission Set, and filter by $Permission.View_Executive_Metrics = TRUE . This provides decoupled, modular governance.
Field Visibility versus Section Visibility
An individual field's visibility can react while the user edits the record. A Field Section's visibility is evaluated after saving, so changing a controlling value while editing does not necessarily make an entire section appear immediately. Test the exact create/edit workflow. Fields hidden for convenience retain their data and remain accessible through other authorized surfaces. Keep universally required fields available for input, or supply valid defaults before the save.
Dynamic Forms does not remove every use of page layouts: related lists, actions where Dynamic Actions is not enabled, and unsupported interfaces can still depend on them. A layout-only difference also does not automatically require a new record type; record types are most useful when business processes or picklist values differ.
Official Source Check
Checked October 19, 2026: Required fields in Dynamic Forms .