Introduction
Dynamic Forms lets admins move fields and sections out of a single Record Detail block and place them individually on a Lightning record page. That makes Lightning App Builder record pages much more modular.
What it changes
- Fields and sections can be placed across tabs and columns.
- Visibility rules can show or hide components based on user or record context.
- Page architecture becomes more composable and targeted.
This is a meaningful admin productivity improvement, but it also changes page governance. Once fields become page components, inconsistent page design becomes easier if there is no shared standard.
Migration
Salesforce provides a migration path for record pages that do not already have Dynamic Forms enabled by default. Migration moves fields and sections from the existing layout model into Lightning App Builder. For many teams, the safest rollout is incremental: migrate one high-value object first, validate usability, and then expand.
Example
A service org may keep basic Case details in the first tab, show escalation fields only when priority is high, and place partner-specific fields in a separate section visible only to partner support users. That is exactly the kind of page shaping Dynamic Forms is meant to support.
Limits and considerations
- Dynamic Forms is supported for most, but not all, standard LWC-enabled objects.
- If the object does not support it, the Fields tab is absent in Lightning App Builder.
- Conditional formatting and advanced page behavior come with object support considerations.