Before Dynamic Forms existed, building a record page that showed different fields depending on record status meant either multiple page layouts assigned to different profiles, or a custom LWC with conditional rendering. Both approaches were fragile, hard to document, and frustrating to maintain. Dynamic Forms changed the equation entirely.
In this guide I’ll cover what Dynamic Forms and Dynamic Actions are, how to set them up, the visibility rule patterns that make them genuinely powerful, and the scenarios where the classic approach is still the right call.
Classic Layout vs. Dynamic Forms: The Core Difference
The classic model assigns page layouts to profile/record type combinations. If you want Sales Reps to see different fields than Managers, you build two layouts. If you want fields to appear or disappear based on a picklist value, you either accept that they’re always visible or you build a custom LWC. Neither is ideal.
Dynamic Forms moves field visibility logic into Lightning App Builder, where each field component on the page can have its own filter criteria — independent of profile assignment and responsive to the live record data.
Classic Layout Approach
A sales manager requests that “Win/Loss Reason” only appears after an Opportunity is Closed. With classic layouts you either show it always (confusing for open deals) or create separate layouts per stage — then multiply by the number of profiles. A mid-size org ends up with 12 layout combinations to maintain.
Dynamic Forms Approach
One record page in App Builder. The “Win/Loss Reason” field gets a single filter: StageName Equals Closed Won OR Closed Lost. It appears instantly as a rep changes the stage — no save required, no extra layouts, no profile juggling.
Setting Up Dynamic Forms
Prerequisites
Dynamic Forms are available for:
- Custom objects (generally available since Summer ‘21)
- Most standard objects: Account, Contact, Lead, Opportunity, Case, and more — added gradually each release
- Not supported: Activity timeline, Notes, Attachments, and some legacy standard objects
To check if an object supports Dynamic Forms, open Lightning App Builder for a record page on that object. If the left panel shows “Fields” as a standalone category (not just inside a “Fields & Relationships” section), you can proceed.
Migration from Classic Layout
- Open Lightning App Builder for the record page you want to migrate
- Click on the existing Record Detail component (the classic fields panel)
- In the right properties panel, click Upgrade Now (or the equivalent prompt Salesforce shows)
- Salesforce will migrate your existing field arrangement from the page layout into individual Field components in App Builder
- Save and activate the page
After migration, each field appears as its own draggable component in the canvas. This is the starting point for adding visibility rules.
Adding Visibility Rules to a Field
- Click on a field component in the App Builder canvas
- In the right panel, find Filter Criteria (under the Component Visibility section)
- Click Add Filter
- Set your conditions:
Field: Opportunity.StageName
Operator: Equals
Value: Closed Won
[+ Add Condition]
Field: Opportunity.StageName
Operator: Equals
Value: Closed Lost
[Condition Logic: 1 OR 2]The field will now only render when the Stage picklist is set to either Closed Won or Closed Lost. Users in the middle of editing a record will see the field appear dynamically as they change the Stage value — no save required.
App Builder has a preview mode that lets you simulate a specific record’s field values to verify that your visibility rules render the correct fields. Use it — especially when your logic involves OR conditions or multiple fields. A misconfigured rule that hides a required field from the wrong profile can cause DML errors that are hard to diagnose.
Component Visibility Filter Patterns
Pattern 1: Stage-Based Field Progression
Show fields progressively as an Opportunity advances. Budget fields appear at Needs Analysis. Contract fields appear at Proposal/Price Quote. Payment details appear at Closed Won. This eliminates the overwhelming wall of fields users see on a new opportunity.
Pattern 2: Record Type Independence
If you have two record types that previously needed two layouts because they required different fields, Dynamic Forms lets you keep a single page and show/hide field groups based on RecordType.DeveloperName. This dramatically reduces layout sprawl.
Pattern 3: Profile-Based Field Display
Profile Name | Equals | Sales ManagerShow bonus calculation fields only to managers. Show territory assignment only to Sales Ops. These rules replace the need for multiple layouts assigned to different profiles.
Pattern 4: Related Field Cascading
Show a field only when a checkbox is ticked, or when a related lookup is populated. For example: show “Contract End Date” only when “Has Active Contract” is checked.
Dynamic Actions
Dynamic Actions extends the same visibility principle to the action buttons at the top of a record page. Instead of every action showing for every user in every state, you can show only the actions relevant to the current context.
Setup
- Open Lightning App Builder for the record page
- Click on the Highlights Panel component at the top of the page
- In the right panel, check Enable Dynamic Actions
- Salesforce will prompt you to migrate actions from the page layout into App Builder
After migration, each action button (New Task, Log a Call, Edit, Submit for Approval, etc.) appears in the component list with a “Filter Criteria” option, identical to Dynamic Forms.
Action Visibility Patterns
Field: StageName
Operator: Equals
Value: Value PropositionHide “Edit” for Closed Won deals older than 90 days (combine with a formula field):
Create a formula field Is_Recent_Closed__c (checkbox) = AND(ISPICKVAL(StageName,'Closed Won'), CloseDate > TODAY()-90). Then filter the Edit action to show only when Is_Recent_Closed__c = True.
Each action can have a form factor filter: Phone, Tablet, or Desktop. This means mobile users can get a streamlined “Quick Update” action while desktop users get the full edit form.
Predefined Actions vs. Custom Quick Actions
Dynamic Actions works with:
- Standard actions: Edit, Delete, Follow, Share
- Quick Actions: record create, field update, custom LWC actions
- Flow-launched actions
Global actions (those defined at the org level, not the object level) do not support Dynamic Actions visibility rules. This is a current platform limitation.
Without Dynamic Actions
Every Opportunity shows “Submit for Approval”, “Clone”, “Delete”, and “Change Owner” to every user regardless of stage or profile. Sales reps accidentally submit closed deals for approval. New users are confused by actions they can’t complete. Support tickets pile up.
With Dynamic Actions
“Submit for Approval” only appears when Stage = Value Proposition. “Delete” is hidden from standard users entirely. “Clone” is desktop-only. The action bar shows exactly what’s relevant to the current user, device, and record state — nothing more.
When NOT to Use Dynamic Forms
Dynamic Forms is powerful but it’s not the right solution in every case.
- Fundamentally different field structures per record type — Classic layouts with record type assignments can still be cleaner when the difference between states is completely different field sets, not just visibility.
- Compact Layout control — Dynamic Forms does not affect compact layouts (the fields shown in Kanban cards, hovers, or related list previews). You still manage those in Classic Setup.
- Unsupported objects — Activity, Event, Task, and several Community objects still require classic layouts.
- Experience Cloud / Sites — Dynamic Forms support in Experience Cloud pages was added in later releases but has limitations. Validate in your specific Experience Cloud context before assuming it works the same as internal pages.
Deployment Considerations
Dynamic Forms page configurations are stored in Lightning Page metadata. When you deploy via change sets or Salesforce CLI, the entire Lightning Page is deployed as a unit. This means:
- Always deploy the full page, not partial changes
- If two developers modify the same page in parallel, the last deploy wins — coordinate carefully
- Test in sandbox before production — visibility rules that reference picklist values can behave unexpectedly if the target org doesn’t have the same picklist values
sf project deploy start --metadata LightningPage:Opportunity_Record_PageLightning Pages are single-file metadata. Two admins editing the same page in separate sandboxes will cause a deployment conflict — the same way two developers editing the same Apex class will. Treat Lightning Page deployments with the same coordination you’d apply to code: assign ownership, communicate before deploying, and merge changes deliberately rather than letting the last deploy win.
The Maintenance Advantage
The argument I make most often for migrating to Dynamic Forms is the maintenance story. When a business analyst says “can we hide the Revenue field from standard users?”, the pre-Dynamic Forms answer involved creating or modifying page layouts, potentially shuffling profile assignments, testing across record types, and deploying a change set. With Dynamic Forms, that change takes three minutes in App Builder and activates immediately.
That speed is compounding. Every field visibility request, every “can we add a stage-specific section”, every “can mobile users see a simpler view” — these go from half-day changes to ten-minute changes. The cumulative hours saved over a year in a mid-size org are substantial.
What page layout challenges have you run into that Dynamic Forms could solve? I’m especially curious whether teams are using it primarily for profile-based visibility or stage-based field progression — drop your use case in the comments.
How did this article make you feel?
Comments
Salesforce Tip