Dynamic Forms
Dynamic Forms is a Salesforce Lightning feature that breaks the traditional page layout into individually placeable, conditionally visible fields on a Lightning record page.
Definition
Dynamic Forms is a Salesforce Lightning feature that breaks the traditional page layout into individually placeable, conditionally visible fields on a Lightning record page. Where a classic page layout defines a static block of fields shown identically to every user, Dynamic Forms lets admins drop fields anywhere on the page, group them into tabs and accordions, and show or hide them based on field values, user roles, or device type.
The feature was the long-awaited successor to traditional page layouts on Lightning. Released for custom objects in 2020 and standard objects (Account, Contact, Opportunity, Case, Lead) starting Winter 2023, Dynamic Forms now covers most of the everyday record-detail experience. It works alongside Dynamic Actions (the parallel feature for record-page actions) and Dynamic Related Lists Single (per-record-page related list filtering) to make Lightning record pages fully configurable through the App Builder. Migration from classic page layouts to Dynamic Forms is a one-way operation; once migrated, the record page becomes the source of truth for field placement.
How Dynamic Forms modernizes Lightning record pages
Static page layout versus dynamic field placement
The classic page layout is one block per record type per profile, with fields placed in fixed sections. The same layout shows to every user, with field-level security determining visibility. Dynamic Forms breaks the layout into a collection of independent Field components dropped onto the Lightning page like any other component. Each Field component can be placed anywhere, sized independently, and conditionally hidden. This is the architectural shift: from one static block to many flexible components.
Visibility rules and conditional display
Each Field component (and each Section component) has a Component Visibility filter. Show the field only when Stage equals Closed-Won, hide it when Status is Draft, display only to users with a specific permission, or based on the device type. The filters use the same Lightning page expression language as other component visibility rules. This is the killer feature: record pages that adapt to context without requiring multiple record types or page-layout proliferation.
Migration from classic page layouts
Lightning App Builder includes a Migrate to Dynamic Forms wizard that converts an existing page layout into a Dynamic Forms record page. The wizard creates Field components matching the existing layout structure. After migration, the record page (not the page layout) controls field placement. Profile-based page layout assignments still work for record-type and profile combinations; the active record page wins for visible field placement, the page layout still handles things like related list assignment.
Sections, tabs, and accordions
Dynamic Forms supports Sections (visual grouping of related fields), Tabs (multiple pages of fields with tab navigation), and Accordions (expandable groups). Each container has its own visibility rules. A complex object like Opportunity can have a Details tab, a Stage History tab, a Forecasting tab, each with conditional sections based on stage, role, or amount. This depth of configuration was impossible with classic page layouts.
Field-Level Security and Dynamic Forms
FLS still applies on top of Dynamic Forms. A user without read access to a field sees nothing regardless of where the Field component sits on the page. Visibility rules are layered on top: FLS is the security floor, visibility rules add contextual UX. Editing a field in Dynamic Forms requires both FLS edit access and a writable Field component (some components can be set to read-only at the page level).
Performance and the field component cost
Each Field component renders independently in the Lightning runtime. Pages with 80+ fields can render more slowly than equivalent classic page layouts because of the per-component overhead. Group fields into Sections and use Tabs to keep visible field counts manageable. For very dense data shapes, consider whether all 100 fields really need to appear on the record page or whether some belong on related views or detail pages.
Dynamic Forms versus Dynamic Actions versus Dynamic Related Lists
Three Dynamic Lightning features work together. Dynamic Forms handles individual field placement on record pages. Dynamic Actions handles the record-page header action bar (which buttons appear, conditionally per user, role, or record state). Dynamic Related Lists Single (DRLS) handles per-record-page related list filtering, sorting, and column selection. The three together make Lightning record pages fully configurable. Adopt all three for any record page worth modernizing; partial adoption leaves capability on the table.
How to migrate to Dynamic Forms
Migrating a record page to Dynamic Forms takes a wizard-driven conversion plus deliberate cleanup. The migration runs without changing what users see initially; the value comes from the conditional visibility rules and reorganization you add afterward. Plan the migration as a two-step exercise: convert mechanically, then optimize for the new capabilities.
- Identify a candidate record page
Pick a record page with fields that would benefit from conditional visibility, reorganization, or device-specific display. Standard objects like Account, Contact, Opportunity, Case, and Lead are now supported alongside custom objects.
- Open the record page in Lightning App Builder
Setup > Lightning App Builder > Edit the page. Confirm the page is the active record page for the target audience. Make a backup by cloning the page if you want to A/B test before activating the new version.
- Run the Migrate to Dynamic Forms wizard
From the Record Detail component or the migration prompt, click Migrate. The wizard converts the existing classic page layout into Dynamic Forms structure. Review the result before saving.
- Reorganize fields and add Sections, Tabs, or Accordions
Drag Field components into new arrangements. Add Section components to group related fields. Use Tabs for major content groups. The drag-and-drop UI makes restructuring fast once the migration completes.
- Configure Component Visibility on fields and sections
For each conditional field, click the field, open the Visibility tab, add filters. Show only when Stage = Closed-Won. Show only to users with the Premier Support permission. Hide on mobile devices. Build up the conditional UX deliberately.
- Test as different user profiles
Save and Activate the page. Log in as users with different profiles and on different record states. Verify the right fields appear, the visibility rules fire correctly, and the page renders within acceptable load time.
- Adopt Dynamic Actions and Dynamic Related Lists Single
Migrate the record-page header actions to Dynamic Actions for conditional action buttons. Replace related list components with Dynamic Related Lists Single for per-page filtering. Full modernization across all three features unlocks the most value.
- Document the migration and revisit assignments
Document what changed for support and training. Confirm record-page assignments (per profile, per record type) align with the new page. Deactivate the old page after a settling period if no rollback is needed.
Drag-and-drop position of each field. Replaces the static section structure of classic page layouts.
Conditional show/hide based on field values, user attributes, or device type. The killer feature of Dynamic Forms.
Visual grouping options for organizing fields into logical chunks with optional conditional visibility.
- Pages with many Field components (80+) can render more slowly than equivalent classic page layouts. Use Tabs and Accordions to limit visible field counts.
- Migration is one-way. Once a record page uses Dynamic Forms, the record page (not the page layout) controls field placement. Plan the migration deliberately.
- Field-Level Security still applies. Users without FLS read see fields as blank regardless of Dynamic Forms visibility rules.
- Component visibility rules are evaluated client-side. The data still loads on the server; hiding a field does not prevent it from appearing in record detail JSON responses.
- Profile-based page layout assignments still apply for things like related list assignment. Dynamic Forms handles field placement; classic page layouts handle some adjacent settings.
Trust & references
Cross-checked against the following references.
- Dynamic Forms OverviewSalesforce Help
- Migrate to Dynamic FormsSalesforce Help
- Component Visibility on Dynamic FormsSalesforce Help
Straight from the source - Salesforce's reference material on Dynamic Forms.
- Dynamic Forms DocumentationSalesforce Help
- Supported Objects for Dynamic FormsSalesforce Help
- Lightning App Builder ComponentsSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does Dynamic Forms enable?
Q2. What's the advantage over traditional page layouts?
Q3. Where is Dynamic Forms configured?
Discussion
Loading discussion…