Dynamic Forms replaces the fields inside the Record Detail component with individual field and field-section components on the Lightning record page. It does not retire the page layout. After you migrate, the layout still drives related lists, still drives actions on most standard objects, and still supplies the printable view, so you now maintain two artefacts per object instead of one, and the boundary between them is not written down anywhere your successor will find it.
The fastest way to know whether your object is supported
Open the record page in the Lightning App Builder and look at the component panel. If there’s no Fields tab, Dynamic Forms isn’t supported for that object — that’s the documented test and it takes two seconds. All custom objects are supported. Objects that aren’t LWC-enabled, including Campaign, Product, Event, and Task, still take their record details from the page layout.
What changes, and what quietly does not
| Element | Controlled by after migration |
|---|---|
| Which fields appear in record details, and their order and grouping | Lightning page (field and Field Section components) |
| Whether a field is required or read-only on the page | Lightning page, per field component |
| Conditional field and section visibility | Lightning page, per-component visibility rules |
| Related lists | Page layout |
| Actions and buttons on standard objects | Page layout, unless dynamic actions is enabled for that object |
| Actions on custom objects | Lightning page, via dynamic actions |
| Printable view fields | Default page layout — not the Dynamic Forms page |
| Highlights panel fields | Compact layout, unchanged |
| Field-level security | Profiles and permission sets, unchanged |
The printable view row is the one that catches people. A record’s printable view is built from the fields on its default page layout, so if you migrated to Dynamic Forms, added four fields to the Lightning page, and never touched the layout, print output and screen output are now different documents. In any org where somebody prints records for a customer or an auditor, that’s a real defect and it produces no error.
Two more that bite. Actions on standard objects come from the record details on the page layout, not from the fields on your page, so migrating and then wondering why the buttons didn’t change is expected behaviour, not a bug. And the Mobile Cards section of the page layout editor has been unsupported since Spring ’20, with items placed there no longer displaying in the mobile app. If you inherited an org that relied on it, migrating is a good moment to stop.
Visibility rules are not security, and this is the expensive mistake
Each field and section component takes filters on record field values, on $User, $Profile and $Permission, and on device form factor. This is genuinely the best part of Dynamic Forms: one page with conditional sections replaces six page layouts, and the condition can be a value on the record rather than only the record type.
What it is not is field-level security. A field hidden by a visibility rule is hidden on that page and nowhere else. It is readable through reports, list views, the API, a data export, a Screen Flow, and any other Lightning page in the org. If the requirement is “sales must not see the margin field,” the answer is field-level security on a permission set. If the requirement is “don’t clutter the page with margin until the deal is Closed Won,” a visibility rule is exactly right.
I’ve seen the confusion go the other way too: a visibility rule hides a required field, the user can’t fill it in, and the save fails with a message about a field that isn’t on their screen. Check your required-field rules against your visibility rules, because the platform won’t.
Migrating, and how to get back
The path is short. Setup → Object Manager → [Object] → Lightning Record Pages, open the page, select the Record Detail component, click Upgrade Now, and step through the wizard picking the page layout whose fields you want. The wizard converts that layout’s sections into Field Section components with the same fields in the same order, then you save and activate.
Before you click it: clone the Lightning page. That is your rollback, and it is the only clean one. The migration writes a new arrangement into the page you’re editing. Going back by hand means deleting every field component and dropping a fresh Record Detail component onto the page, which loses whatever tuning you’d already done. Your page layout itself is untouched by the migration (the wizard reads it, it doesn’t consume it), so a Record Detail component put back on the page renders the layout’s fields exactly as before.
Migrate one object at a time, and start with an object that has a real conditional requirement. Migrating a 12-field custom object with one layout gains you nothing and costs you a second artefact to maintain.
The tradeoffs, named
Two artefacts, one unwritten boundary. A new admin asked to add a field will find the page layout, add the field there, and see nothing change on screen. That confusion is now permanent unless you document it. Rename the migrated layout to something like Opportunity Layout (related lists and actions only) — it’s the cheapest documentation you’ll ever write.
Auditability moves the wrong way. The record-type-by-profile layout assignment grid was ugly, but it was one screen you could read top to bottom. Its replacement is component-level visibility rules scattered down a page, with no view that answers “under what conditions does this user see this field?” You’ve traded a bad interface for distributed logic, and distributed logic is harder to review.
Debugging “where’s my field” gets slower. Before migration a missing field had two causes: field-level security or the layout. After migration it has three: field-level security, the visibility rule, or never added to the page. Work them in that order — check FLS first, because it’s the one that also affects reports.
Metadata diffs get noisier. Field arrangement moves from Layout XML into FlexiPage XML, where every field is a component with an ordered position. Small changes produce large diffs, and merge conflicts on a busy record page are unpleasant. If two people edit the same Lightning page in different sandboxes, expect to redo one of them.
Frequently asked
Do I still need page layouts after migrating?
Yes. Keep the layout assigned and maintained for related lists, actions on standard objects, and the printable view. You can strip its field sections down, but don’t delete the layout or unassign it.
Does hiding a field with a visibility rule secure it?
No. It hides the field on that page only. Reports, list views, the API, and exports all still return it. Use field-level security when the requirement is access, and visibility rules when the requirement is clutter.
Can I use Dynamic Forms and record types together?
Yes, and it’s often the point. Keep record types for picklist value sets and business processes, then replace six page layouts with one Lightning page whose sections have visibility rules keyed on record type. The record types stay. The layout proliferation goes.
Why didn’t my buttons or related lists change after migration?
Because they were never part of the migration. Actions on standard objects come from the record details on the page layout, and related lists come from the layout too. Edit the layout for those, or enable dynamic actions where the object supports it.
What happens to the page layout the wizard read?
Nothing. The migration copies the field arrangement onto the Lightning page and leaves the layout as it was, which is why putting a Record Detail component back gives you the old page immediately.
Is there a limit on how many field components a page can hold?
There are documented Lightning page component limits, and a 200-field object rendered as 200 individual components is a page you should be splitting across tabs or accordions anyway, both for load time and for anyone trying to read it. Check the current figure in Dynamic Forms Limitations before you plan a very large page.
Reference: Break Up Your Record Details with Dynamic Forms, Migrate a Record Page to Dynamic Forms, Dynamic Forms Limitations, Dynamic Forms Tips and Considerations, Dynamic Forms Known Issues, and Deciding When to Use Lightning App Builder or the Page Layout Editor, Salesforce Help.
