Why Dynamic Forms Matter
Classic page layouts put every field on every record page. Users see 200 fields when they need 15. Conditional visibility was a hack via record types and page layout variants.
Dynamic Forms fix this. You place fields (and field sections) directly on a Lightning record page via App Builder, and each field has its own visibility rules. Admins control the page layout in one place — Lightning App Builder — instead of juggling separate page layouts and record types.
If you’re still assigning page layouts in 2026, you’re using old tooling.
What Dynamic Forms Actually Is
Dynamic Forms is a feature of the Lightning App Builder. On a record page, you break out the record detail component into individual field components (or field sections). Each field has:
- A visibility rule (always, or conditional).
- An optional read-only override.
- Placement freedom — any tab, any column.
The page layout you used to configure in Setup becomes the App Builder page layout.
Where It’s Available
Dynamic Forms is generally available for most standard and custom objects. Check the current release notes — Salesforce has rolled availability out progressively by object. If you don’t see “Upgrade Now” in App Builder for your object, it may not yet support Dynamic Forms.
For legacy contexts (classic pages, specific mobile views), classic layouts still render. Dynamic Forms applies to Lightning Experience.
The Visibility Rule Engine
Every field can have a visibility filter. Filters can reference:
- Record field values.
- User profile.
- User permissions.
- Device type.
- Custom conditions (combinations of the above).
Example rules:
- “Show Discount field only if Status is ‘Negotiation’ and user has the Sales Manager permission set.”
- “Show Compliance Hold field only if Amount > 100000.”
- “Hide internal notes from Community users.”
Rules are in the field’s properties panel in App Builder. Multiple conditions can be AND’d together via the filter builder.
Pattern 1: Role-Based Visibility
Different roles see different fields on the same page.
- Sales reps see pipeline fields.
- Service agents see support fields.
- Executives see summary fields.
Historically, orgs solved this with multiple page layouts assigned by profile. Dynamic Forms lets one page adapt — a single source of truth.
Use profile or permission set as the visibility condition per field or section.
Pattern 2: Progressive Disclosure
Show fewer fields initially; reveal more as the record advances.
- Early-stage Opportunity: Name, Account, Stage, Close Date.
- Qualified Opportunity: adds Budget, Decision Criteria, Decision Maker.
- Negotiation Opportunity: adds Discount, Terms, Legal Review.
Each section’s visibility is conditional on Stage. Users aren’t overwhelmed on new records; detailed fields appear when they’re needed.
Pattern 3: Privacy Sensitivity
Hide regulated or sensitive fields from users who don’t need them.
- SSN field visible only to HR Manager profile.
- Compensation field visible only above Director role.
- Medical notes visible only to licensed users via permission set.
Field-level security is still the ultimate guard, but Dynamic Forms visibility layers on top — even users with permission don’t see the clutter unless relevant.
Pattern 4: Guidance Context
Dedicate a section to user guidance that appears only when relevant.
- “You have overdue cases” callout on the account page — visible only if related case count exceeds X.
- “Renewal window open” — visible in the 60 days before renewal date.
Information lives on the record page, visible to the right user at the right time.
Section Design
Dynamic Forms organizes fields into sections with labels. Good section design:
- 5–8 fields per section — more becomes dense.
- Section labels describe purpose — “Deal Terms,” “Key Contacts” — not “Section 1.”
- Group by user task — the fields a user updates together belong in the same section.
- Two-column layout for desktop; collapse to one column on mobile automatically.
Performance
Each conditional field is evaluated at render time. Hundreds of conditions on one page slow page load.
Guidelines:
- Keep field-level conditions under a few dozen per page.
- Group fields under a section-level condition where possible — one evaluation instead of many.
- Avoid conditions referencing fields that require a lookup (non-indexed cross-object references).
Measure with the Lightning Inspector browser extension if performance matters.
Migration From Page Layouts
For an existing object with 3+ page layouts assigned by profile:
- Inventory all page layouts and which fields are on each.
- Design a single Dynamic Forms page with conditional visibility.
- Build in App Builder.
- Deploy to sandbox.
- Test with each profile that had a distinct layout. Validate each user sees the right fields.
- Activate as the default Lightning Experience record page.
- Retire the old page layouts.
Migration for a complex object can take days. Budget accordingly.
Packaging
Dynamic Forms pages are metadata. They deploy via change sets, packages, and SFDX. They version.
One gotcha: a Dynamic Forms page references specific fields; if a field is renamed or removed, the page breaks. Discipline around schema changes is more important when pages are data-driven.
Anti-Patterns
Replicating every old layout. If you had 12 page layouts, you don’t need 12 conditional branches. Collapse where possible — many “different” layouts were minor variations.
Over-granular field conditions. A dozen fields each with its own condition is a maintenance nightmare. Group conditions at the section level when the group shares visibility logic.
Using visibility in place of field-level security. Visibility hides the field in the UI. It doesn’t prevent API access. Sensitive fields still need FLS.
Forgetting mobile. Dynamic Forms renders on mobile — test it. Dense layouts that work on desktop often feel cramped on phone.
Frequently Asked Questions
Do Dynamic Forms work on Salesforce Mobile?
Yes — with responsive rendering. Mobile collapses to single column.
Are there limits on the number of fields?
Lightning App Builder enforces page-level field count limits (a few hundred). Hitting that limit is usually a design smell.
Can I use Dynamic Forms in Experience Cloud?
Dynamic Forms in the Experience Builder is supported for Customer Service templates and custom pages. Feature parity continues to expand.
How do they compare to Dynamic Actions?
Related feature. Dynamic Actions control which buttons appear conditionally. Dynamic Forms control which fields appear. Use both together for a context-aware page.