Dynamic Forms vs Page Layouts in Salesforce
They aren’t rivals — they do different jobs and hand work off to each other. Here’s exactly what each one controls, and where the page layout still runs the show.
Dynamic Forms vs page layouts is not an either/or choice. A page layout delivers a record’s fields as one Record Detail block and still drives related lists, buttons, mobile, and more. Dynamic Forms breaks that block into individual Field and Field Section components you place — and conditionally show or hide — right in the Lightning App Builder. Dynamic Forms replaces the page layout only for field placement on a Lightning record page. It does not retire it.
What Dynamic Forms and page layouts each do
For years, the page layout was the whole record experience: it decided which fields appeared, in what order, alongside related lists, buttons, and actions. In Lightning Experience, a page layout still supplies fields through the Record Detail component — one monolithic block. The only way to change the fields inside that component is the page layout editor.
Dynamic Forms changes that. When you upgrade a Lightning record page, the single Record Detail block is replaced by individual Field and Field Section components. You can drag those anywhere on the canvas — into tabs, accordions, or two-column regions — and attach component visibility rules so a field or section appears only when it matters (based on record data, the user’s profile, or the device). All of that happens inside the Lightning App Builder, with no trip to the page layout editor.
The trade-off is scope. Dynamic Forms only exists on objects that support Lightning Web Component (LWC) record pages. On a non-LWC-enabled object, the “Fields” tab never appears in App Builder, and the page layout remains your only field tool.
What still comes from the page layout
This is where most confusion lives. Turning on Dynamic Forms moves field placement to the Lightning page — but several parts of the record still originate on the page layout (or its sibling, the compact layout). Here’s who supplies what once Dynamic Forms is on:
| Record element | Where it comes from |
|---|---|
| Field placement, sections, visibility rules | Dynamic Forms (Field / Field Section components) |
| Related lists | Page layout — unless you add the Dynamic Related Lists component |
| Buttons & actions | Page layout by default; Dynamic Actions moves this to the Lightning page |
| Highlights Panel fields | Compact layout |
| Mobile field display (if not opted in to Dynamic Forms on Mobile) | Page layout, via the Record Detail - Mobile component |
| Inline edit in list views | Requires the field on a page layout assigned to the user’s profile |
| Non-LWC-enabled objects | Page layout only (Dynamic Forms not supported) |
Two rows deserve extra attention. First, actions: on standard objects, the buttons and actions on a record come from the page layout unless you deliberately add Dynamic Actions to the Lightning page. Second, inline edit in object-home list views: a field is only inline-editable there if it lives on a page layout that’s assigned to the user’s profile — a subtle dependency that survives long after you’ve moved everything else to Dynamic Forms.
A Dynamic Forms visibility rule controls whether a field renders on the page — it is not field-level security. Whether a user can actually access a field’s data is governed by FLS on their profile and permission sets. A field hidden by a visibility rule can still be reachable through reports, list views, or the API if FLS grants access. Never treat a visibility rule as a way to protect sensitive data.
How to migrate a page layout to Dynamic Forms
Migration is a guided, reversible-in-practice wizard, not a data change. From a Lightning record page in the App Builder, select the Record Detail component and click Upgrade Now. The wizard asks you to pick a single source page layout, then swaps the Record Detail block for the fields and sections from that layout — now individually configurable.
The one-layout limit trips people up. If an object has several page layouts feeding different record types, the wizard pulls from one of them; you rebuild the rest by adding the missing fields into new sections and controlling them with visibility rules. That consolidation is the point — Dynamic Forms lets you collapse many near-duplicate layouts into one Lightning page.
If you haven’t opted in to Dynamic Forms on Mobile and the page supports the phone form factor, migration adds a Record Detail - Mobile component so mobile users still see the standard detail fields from the page layout. Field and Field Section components were desktop-only for a long time; once you opt in to Dynamic Forms on Mobile, they render on phones too — so decide which experience you want before you ship.
Dynamic Forms vs page layouts: which to use when
Reach for Dynamic Forms when you want conditional field visibility, fewer page layouts and record types, a cleaner two-column layout, faster-loading pages, or field placement precision — and when your Lightning page assignment (by app, profile, record type, or form factor) needs to be sharper than a page layout’s profile-and-record-type assignment allows.
Stick with the page layout when the object isn’t LWC-enabled, when you’re standing up a quick baseline structure, or when you specifically need one of the things the layout still owns — related lists, actions on standard objects, list-view inline edit, or the Salesforce Classic experience. In most orgs the honest answer is both: Dynamic Forms shapes what users see on the Lightning page, while the page layout keeps supplying the plumbing underneath.
Editions matter too. Page layouts are available in every edition; the Lightning App Builder — and therefore Dynamic Forms — is available in Group, Professional, Enterprise, Performance, Unlimited, and Developer editions.
One more myth to retire: Dynamic Forms does not replace record types. Record types still own picklist filtering and business processes, and the record-type-to-page-layout assignment still resolves per profile. Dynamic Forms simply means you often no longer need a separate layout for each record type. For the full picture of how those two interact, see our brief on Record Types vs Page Layouts, and for the broader UI decision — page layouts, Lightning pages, and Dynamic Forms together — see our pillar guide “Page Layouts, Lightning Pages, and Dynamic Forms: How to Choose.”
High-Yield Exam Facts
- Not a replacement: Dynamic Forms replaces the page layout only for field placement on a Lightning record page; the page layout stays.
- LWC-enabled only: Dynamic Forms works only on objects that support LWC record pages — non-LWC objects use page layouts.
- Visibility ≠ FLS: Component visibility rules hide fields on the page but never restrict data access; FLS on profiles and permission sets does that.
- Page layout still supplies: related lists, standard-object actions, compact-layout Highlights Panel fields, mobile detail (via
Record Detail - Mobile), and list-view inline edit. - Migration: Record Detail → Upgrade Now → pick one source page layout; consolidate the rest with visibility rules.
Test Your Knowledge
Scenario questions on page layouts, Dynamic Forms, and Lightning pages.
Verified against the official Salesforce Summer ’26 documentation, including Deciding When to Use Lightning App Builder or the Page Layout Editor and Break Up Your Record Details with Dynamic Forms. Study smarter at CertifySF.com.