What You'll Learn
How Dynamic Forms replaces the record type / page layout model, the conditional visibility rules for fields and sections, Dynamic Actions for context-aware button surfaces, current support limitations, and when to use Dynamic Forms versus custom LWC components.
The Problem with Page Layouts
The traditional Salesforce record page model is: assign users to record types, assign record types to page layouts, configure the page layout with all fields that any user on that layout might need. The result is cluttered record pages — 40-field layouts where any given user actually uses 15 fields depending on the record's stage or their role.
The workaround was profile-specific page layouts: assign different layouts per record type per profile, creating a matrix explosion of layout maintenance. An org with 8 record types and 12 profiles has a theoretical maximum of 96 page layout assignments to manage. This is where Dynamic Forms becomes genuinely valuable.
How Dynamic Forms Works
Dynamic Forms replaces the traditional "Fields" component on a Lightning record page with individual field components and field section components. Each field or section can have visibility rules that show or hide it based on:
- Field values on the current record (e.g. show "Reason for Loss" only when Stage = "Closed Lost")
- User profile or permission set (e.g. show "Internal Notes" only to managers)
- Device type (e.g. hide supplementary fields on mobile)
- Record type (e.g. show the "Healthcare Fields" section only on Healthcare record type)
Visibility evaluation is client-side and instant — no page reload when the triggering field value changes. This creates the "smart form" experience where fields contextually appear as the user fills in data.
// Dynamic Forms visibility rule examples (configured in Lightning App Builder)
// Show field only on Closed Lost opportunities
Field: Close_Lost_Reason__c
Visibility Filter: Stage EQUALS "Closed Lost"
// Show section based on permission set
Section: Executive Summary Fields
Visibility Filter: Current User Permission Set CONTAINS "Executive_Access"
// Show section on specific record type
Section: Healthcare Compliance
Visibility Filter: Record Type NAME EQUALS "Healthcare"
// Combined condition (AND logic)
Field: Competitor__c
Visibility Filter:
Stage EQUALS "Negotiation/Review"
AND
Account_Industry__c EQUALS "Technology"Dynamic Actions: Context-Aware Buttons
Dynamic Actions extend the same conditional visibility concept to the action bar — the "Edit," "Delete," "New Case," and custom Quick Action buttons on a record page. Without Dynamic Actions, the action bar shows a static set of buttons defined by the page layout. With Dynamic Actions, each button can have visibility rules using the same filter conditions as Dynamic Forms.
Practical examples:
- Show "Approve Quote" only when Status = "Pending Approval" and the current user has the "Quote Approver" permission set
- Hide "Delete Account" for all users except System Administrators
- Show "Assign to Territory" only when the Territory field is empty
- Show different Quick Actions on mobile versus desktop
Current Limitations and Gaps
Dynamic Forms is not a full replacement for all record page scenarios as of 2026:
- Object support: Dynamic Forms is generally available for custom objects and a growing list of standard objects. Some standard objects (notably some financial services objects) are not yet supported.
- Required fields: Required fields configured at the field level (not the page layout level) still appear regardless of Dynamic Forms visibility rules. Required field enforcement is object-level, not form-level.
- Mobile limitations: Dynamic Actions on mobile requires the Lightning Mobile app — the Salesforce Mobile app has some feature gaps versus the browser experience.
- Read-only fields in visibility conditions: Visibility conditions can reference field values, but if that reference field is on a related object (e.g., Account.Industry on an Opportunity record), it cannot be used directly in the condition — you need a formula field that mirrors the value onto the record.
When to Use Dynamic Forms vs Custom LWC
Use Dynamic Forms when:
- Visibility logic is based on field values, record types, profiles, or permission sets on the current record
- The business team needs to configure and modify visibility rules themselves in Lightning App Builder
- The use case is standard field display — no custom rendering, interactivity, or data transformation needed
Use a custom LWC when:
- Visibility depends on data from related records (parent Account fields on a Contact page)
- The field requires custom formatting, input validation, or interactive behaviour
- The condition involves complex computations or external API data
- The object is not yet supported by Dynamic Forms
Key Takeaways
- Dynamic Forms replaces page layout field assignment with per-field and per-section visibility rules configured in Lightning App Builder.
- Visibility rules are evaluated client-side — instant response, but limited to data on the current record.
- Dynamic Actions apply the same conditional visibility model to action bar buttons and Quick Actions.
- Dynamic Forms is a UX feature, not a security feature — FLS must still enforce field-level data access.
- Use Dynamic Forms for standard field display with declarative conditions; use LWC for complex logic or related-object data.
- Required fields set at the object level appear regardless of Dynamic Forms visibility rules.
Check Your Understanding
1. A Dynamic Forms visibility rule hides a sensitive salary field for all non-HR users. Does this prevent non-HR users from reading the salary data via SOQL?
2. You want to show an "Approve" button on an Opportunity only when Stage = "Pending Approval" AND the user has the "Approver" permission set. Which feature handles this?
3. A Dynamic Forms visibility condition needs to reference a field on the parent Account from a Contact record. What is the correct approach?
Discussion & Feedback