9.1 Dynamic Forms & Conditional Component Visibility

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:

1. 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.
2. 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.
3. 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.
4. 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:

1. Open an existing Lightning record page in Lightning App Builder.
2. Click on the legacy Record Detail component.
3. In the component properties pane on the right, click the Upgrade Now button.
4. The migration wizard prompts the administrator to select an existing Page Layout to use as the source template.
5. 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.
6. After migration, the legacy Record Detail component is removed, and administrators can immediately configure conditional visibility rules or rearrange fields across tabs.

---

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: $\text{3 Roles} \times \text{4 Regions} = 12 \text{ Page Layouts} + 12 \text{ 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.

---

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:

1. 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').
2. 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.
3. 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

---

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.