The short answer: Dynamic Forms moves fields out of the page layout and onto the Lightning record page, where each field and section can carry visibility rules. Dynamic Actions does the same for buttons. Neither retires the page layout, because related lists, the compact layout assignment and the Classic experience still read it. So you end up maintaining both, and the trick is knowing which one owns what.
What each one gives you
Dynamic Forms replaces the Record Detail component with Field Section components holding individual fields. Every field and every section gets its own visibility rules, so a set of finance fields can appear only when the stage is Closed Won and the user holds a particular permission.
Dynamic Actions moves the action bar off the layout’s Salesforce Mobile and Lightning Experience Actions section and onto the Highlights Panel component, again with per-action visibility rules. An Escalate button that only exists for high-priority cases owned by the running user‘s team is three clicks rather than a workaround.
Migrating from a page layout
The App Builder offers an upgrade on the Record Detail component. It reads the assigned page layout and reproduces its sections and fields as Field Sections. This is a faithful copy, which means it copies the mess too. A layout with forty fields in one section becomes a Lightning page with forty fields in one section.
Do the tidying as part of the migration, because you will not come back to it. A reasonable sequence:
- Clone the record page first, so the live one is untouched while you work.
- Run the upgrade, then delete fields nobody has used. Field usage from a report on recent records is better evidence than asking.
- Add visibility rules to the sections that only apply to one team or one stage.
- Activate for a small profile first, not the org default.
One field, one place. A field placed twice on the same page with different rules will eventually contradict itself, and the person debugging it will not enjoy the afternoon.
What is still layout-driven
This is the part that surprises people, so it is worth being blunt about it.
- Related lists. Which ones appear, in what order, with which columns, all still come from the page layout.
- The compact layout. Assigned on the object by record type, and it fills the highlights panel regardless of Dynamic Forms.
- Layout assignment itself. Profiles are still assigned page layouts, and that assignment still matters for the surfaces above.
- Salesforce Classic. If any user or process still touches Classic, the layout is what they see.
- Some integrated surfaces. Tools that render a record outside Lightning read the layout.
The practical consequence is that you cannot delete the page layouts. Keep them tidy enough that the related lists are right, and stop worrying about the field arrangement on them.
Visibility rules are not security
Say this out loud in the design review. A field hidden by a visibility rule is still returned by the API, still reportable, still in list views, still in exports. If the requirement is that a group of users must not see a value, the answer is field-level security, and Dynamic Forms is the wrong tool.
Where visibility rules shine is reducing noise for people who are permitted to see everything and only need six fields today.
Cost
Each visibility rule is evaluated client-side when the record renders, and each field placed individually is its own component in the page definition. A page with two hundred individually placed fields and rules on most of them renders noticeably slower than one with six sections. Group fields into sections and put the rule on the section wherever the logic allows it.
Frequently asked
Does Dynamic Forms work on mobile? Yes, and the record page assigned to the phone form factor is a good place to use visibility rules aggressively, since screen space is the scarcest resource there.
Can I make a field required through Dynamic Forms? You can mark it required on the page, which enforces it in that interface only. Anything that has to hold everywhere belongs in a validation rule or on the field definition.
Why has my button disappeared after enabling Dynamic Actions? Because the action bar now comes from the Highlights Panel component, and it starts from whatever you added there. Actions on the page layout are no longer consulted for that page.
Is it available on every object? Custom objects and a long and growing list of standard ones. Check the object in the App Builder rather than trusting a list you read last year, since the supported set has expanded steadily.
