Dynamic Forms

Why Dynamic Forms Matter

For years, Salesforce administrators were stuck with a rigid model: every field a user saw on a record was dictated by a page layout, and the only way to show different fields to different people was to create more page layouts, more record types, and more profile assignments. The result was layout proliferation: organizations with 15 or 20 Opportunity layouts that differed by only one or two fields. Dynamic Forms solve this problem. They let you break the page layout apart and place individual fields and sections directly on a Lightning record page, then control who sees each field, and when, using the same visibility rules you already use for other Lightning components.

On the Advanced Administrator exam, Dynamic Forms sit inside the Advanced Objects and Applications domain, which covers Lightning App Builder, record pages, page layouts, record types, and user experience design. Expect scenario questions where a business asks for conditional field display, a reduction in page layout count, or a cleaner, faster record page. Knowing when Dynamic Forms are the right answer, and when they are not, is the skill being tested.

What Dynamic Forms Are

Dynamic Forms are a Lightning App Builder capability that lets you add Field Section components and individual Field components to a Lightning record page, independent of the Record Detail component and the page layout it mirrors. Instead of a single monolithic block of fields, you build the record page from granular pieces:

• Field Section: a container component that holds fields. You can give it a header, choose one or two columns, make it collapsible, and apply visibility rules to the whole section.
• Field: an individual field component dragged from the Fields tab in the App Builder palette. Each field can have its own visibility rule and can be marked Required or Read-Only at the page level.
• Blank Space: a spacer you can place within a Field Section to control alignment (added in more recent releases).

Dynamic Forms were first released for custom objects and were later extended to standard objects such as Account, Person Account, Contact, Opportunity, Lead, Case and many others. The exam may still reference the history, so remember: custom objects first, standard objects later, and today most commonly used standard objects are supported. A few standard objects still rely on the traditional Record Detail component.

How Dynamic Forms Work

1. Enabling Dynamic Forms on a page
Open a Lightning record page in Lightning App Builder. If the page uses a Record Detail component, select it and click Upgrade Now (sometimes labeled Migrate). Salesforce walks you through a wizard that reads the assigned page layout and converts its sections and fields into Field Section and Field components. You choose which page layout to use as the source. After migration you can delete the Record Detail component, because the fields now live directly on the page. Alternatively, you can start fresh by dragging Field Section components onto a page and adding fields from the Fields tab.

2. Component visibility rules
This is the heart of Dynamic Forms. Select any Field or Field Section and use Set Component Visibility to add filters. Filters can be based on:
• Record field values (for example, show the Lost Reason field only when Stage equals Closed Lost).
• User attributes (profile, role, user record fields, or custom permissions assigned to the user).
• Device (desktop or phone form factor).
• Advanced criteria such as the record owner or related record fields.
Multiple filters can be combined, and you choose whether all or any must be true. Because visibility is evaluated at run time, a field can appear or disappear as the user edits the record, with no page refresh.

3. Required and Read-Only overrides
Each Field component has Required and Read-Only checkboxes. These are page-level settings, exactly like the red-bar required and read-only options on a classic page layout. Important rule: field-level security always wins. If a user lacks edit access via FLS, marking the field editable on the page does nothing. If a field is universally required at the object level, it is required everywhere regardless of the page setting, and if you remove a universally required field from a Dynamic Form, users may be unable to create records from that page. Salesforce warns you about this in the App Builder.

4. Field-level security still governs access
Dynamic Forms do not replace profiles or permission sets. A field hidden by FLS will never render on a Dynamic Form. Visibility rules are a user experience tool, not a security tool. The exam frequently tests this distinction: if a question says sensitive data must be protected, the answer is FLS or permission sets, not component visibility.

5. Page assignment
Once a page uses Dynamic Forms, you activate it the usual way: as the org default, as the app default, or by App, Record Type, and Profile. This means you can combine Dynamic Forms with record types when the record type drives picklist values or business process, but you no longer need a separate page layout just to hide a few fields. One Lightning page with visibility rules can replace many page layouts.

6. Performance and design
Salesforce recommends keeping forms reasonably sized and moving less-used fields into Tabs or Accordion components. Fields inside a non-active tab are loaded lazily, which improves page load time. Placing dozens of individual Field components on the page without structure can degrade performance, so grouping fields in Field Sections and using tabs is the best practice.

7. Dynamic Forms on Mobile
Originally, the Salesforce mobile app ignored Dynamic Forms and fell back to the page layout. Now you can enable Dynamic Forms on Mobile in Setup (under Salesforce Mobile App settings). Once enabled, mobile users see the same Field Sections and visibility rules as desktop users, and you can use device-based visibility filters to tailor the experience for phones.

8. Cross-object fields
Dynamic Forms for related objects let you display read-only fields from a parent record reached through a lookup, for example showing Account Industry on a Contact page as a Field component. These are display-only and are a popular exam distractor against formula fields: if the requirement is simply to display parent data on the page, a cross-object Dynamic Form field avoids creating a formula field.

Dynamic Forms versus Related Features

Know the siblings, because the exam loves to mix them up:
• Dynamic Forms: control fields and field sections.
• Dynamic Actions: control which quick actions and buttons appear in the Highlights Panel, with the same visibility filters. Actions are no longer tied to the page layout once Dynamic Actions are enabled.
• Dynamic Related Lists (Dynamic Related List - Single): control related lists, their columns, filters, and sort directly on the page.
• Page layouts: still control compact layouts indirectly, Salesforce Classic, some mobile scenarios when Dynamic Forms on Mobile is off, and the fallback for objects that do not support Dynamic Forms.
• Compact layouts: still define the Highlights Panel fields; Dynamic Forms do not change this.

Key Limitations to Remember

• Not every standard object supports Dynamic Forms; check the object before promising a solution.
• Dynamic Forms do not apply in Salesforce Classic.
• Experience Cloud sites and some embedded contexts still rely on the page layout or their own record detail components.
• Visibility rules are not a security mechanism; they are a display mechanism.
• Do not keep both a Record Detail component and Field Sections for the same fields on one page; it duplicates fields and confuses users.
• Very large forms with hundreds of individually placed fields can slow the page; use tabs and accordions.

Exam Tips: Answering Questions on Dynamic Forms

Tip 1: Look for the phrase 'without creating additional page layouts'. When a scenario asks to show or hide fields based on record values, user profile, or custom permission, and explicitly or implicitly wants to avoid more layouts or record types, Dynamic Forms with component visibility is almost always the answer.

Tip 2: Separate experience from security. If the question mentions confidential data, compliance, or that users must not be able to access a field, choose field-level security or permission sets. If it mentions reducing clutter, showing fields only when relevant, or simplifying the page, choose Dynamic Forms.

Tip 3: Know the component names. Expect answer options that name Field Section, Field, Record Detail, Upgrade Now, and Set Component Visibility. An answer that says to edit the page layout to achieve conditional visibility is wrong; page layouts cannot do conditional field display.

Tip 4: Watch for the mobile trap. If users report that fields look different on the Salesforce mobile app than on desktop after Dynamic Forms were implemented, the answer involves enabling Dynamic Forms on Mobile in Setup, or using a device-based visibility filter.

Tip 5: Fields versus actions versus related lists. Read carefully whether the requirement concerns a field, a button or quick action, or a related list. Dynamic Forms handle fields, Dynamic Actions handle actions, Dynamic Related Lists handle related lists. Picking the wrong sibling is the most common mistake.

Tip 6: Performance questions point to tabs and accordions. If a record page with Dynamic Forms loads slowly, the correct remediation is to reorganize fields into Tabs or Accordion components so that non-visible sections load lazily, not to revert to a page layout.

Tip 7: Required and Read-Only are page-level, FLS is global. A question stating that a field marked Required on the Dynamic Form is still editable or still required elsewhere is testing whether you know that page-level settings apply only to that page and that FLS and universally required settings override them.

Tip 8: Record types still have a role. Dynamic Forms reduce the number of page layouts you need, but record types still control picklist values and business processes. If the scenario needs different picklist values per sales process, you still need record types; if it only needs different fields shown, Dynamic Forms alone will do.

Tip 9: Cross-object display without formulas. If a requirement is to display parent record information on a child record page purely for reference, consider the Dynamic Forms related-object field option before defaulting to a cross-object formula field.

Tip 10: Eliminate the impossible. Any option that proposes Dynamic Forms in Salesforce Classic, or uses visibility rules to secure data, or claims the page layout can show fields conditionally, can be eliminated immediately. That usually leaves two plausible answers, and the right one is the one that matches the exact object in the question (field, action, or related list) and the exact requirement (display versus access).

Summary

Dynamic Forms move field placement and conditional visibility from the page layout into the Lightning App Builder, giving administrators a single, flexible record page that adapts to the record, the user, and the device. For the exam, remember the mechanics (Field Section, Field, Upgrade Now, component visibility, Required and Read-Only overrides), the boundaries (FLS governs access, not every object or context is supported, mobile requires a setting), and the family (Dynamic Actions and Dynamic Related Lists). Master those three areas and Dynamic Forms questions become some of the most predictable points on the Advanced Administrator certification.