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.