Page Layouts, Lightning Pages, and Dynamic Forms: How to Actually Choose Between Them

The Confusion Every Admin Faces

Even experienced Salesforce admins and BSAs hit moments where the UI configuration feels like a maze. You configure a field in Dynamic Forms, but it still appears via the Page Layout. You add a button to the Page Layout, but it doesn’t show on the Lightning record page. You build a Lightning Page Variation for one Profile, but a different Profile sees the wrong page anyway.

These aren’t edge cases — they’re symptoms of a deeper issue. Salesforce’s UI configuration isn’t a single feature with one source of truth. It’s a layered architecture, and each layer has its own rules, scope, and override behavior. Until you internalize the layers and how they interact, every UI decision feels like a guess.

Here are the four most common questions admins and BSAs run into:

The answer to all four questions becomes obvious once you understand how Salesforce’s UI layers stack. Let’s build that mental model.

The Salesforce UI Layer Stack

When a user opens a record in Lightning Experience, Salesforce evaluates a stack of configuration layers in a specific order. Each layer either contributes to or overrides what the user sees. Understanding this order is the foundation for every UI decision.

Click any layer below to see what it controls and how it interacts with the others.

Page Layouts: What They Still Control

Page Layouts are often called “legacy” — but that framing is misleading. Even in 2026, Page Layouts still control multiple aspects of the user experience that no other configuration replaces. The mistake admins make is assuming Page Layouts are only about field display on desktop Lightning. That hasn’t been true for years.

What Page Layouts Still Do (Spring ’26)

The Page Layout’s Real Job in 2026

Think of Page Layouts as the structural backbone. They define what’s available — buttons, actions, field sets, related lists, mobile rendering. The Lightning Page and Dynamic Forms then decide how those elements appear on desktop Lightning. If you’re configuring something that needs to work everywhere (mobile, Classic, integrations), it goes on the Page Layout. If you’re configuring something for desktop Lightning specifically, it goes on the Lightning Page or Dynamic Forms.

Lightning Record Pages: The New Foundation

Lightning Record Pages are the canvas for desktop Lightning Experience. Built in Lightning App Builder, they let you compose a record page using components — Highlights Panel, Tabs, Related Lists, custom Lightning components, and (when activated) Dynamic Forms.

Page Variations and Assignment

A single object can have multiple Lightning Record Page variations. Each variation can be assigned to specific App, Record Type, and Profile combinations. This is where most admin confusion starts — the assignment logic has a strict precedence order.

Component Visibility Rules

Each component on a Lightning Page can have visibility rules — show this Highlights Panel only when Stage = “Closed Won,” show this Related List only when User.Role = “Sales Manager.” Visibility rules support filters based on record fields, user fields, and device type.

This is a powerful but underused feature. Many admins reach for Lightning Page Variations when component visibility rules would be simpler. If you’re showing different components to different users on the same record, visibility rules on a single page are easier to maintain than multiple page variations.

Dynamic Forms: The Granularity Layer

Dynamic Forms add field-level granularity to the Lightning Page. Instead of relying on the Page Layout’s static field arrangement, Dynamic Forms let you place individual fields anywhere on the page, organize them into custom Field Sections, and apply visibility rules at the field level.

What Dynamic Forms Override

When Dynamic Forms is enabled on a Lightning Page, it replaces the Page Layout’s field arrangement on that page. The Page Layout still drives buttons, related lists, and mobile — but field display on desktop is now controlled by Dynamic Forms.

When Dynamic Forms Is the Right Choice

• You need conditional field visibility based on record values (show “Loss Reason” only when Stage = “Closed Lost”)
• You need conditional sections (show “Renewal Details” only when Type = “Renewal”)
• You’re building a UI that varies significantly across record states
• You want to migrate away from Page Layout dependency for field display
• You need field-level placement flexibility (put fields in different page regions, not just stacked sections)

When Dynamic Forms Is Overkill

• Your field arrangement is mostly static and doesn’t need conditional logic
• You only have a few simple sections that don’t change based on record data
• You want minimal admin maintenance overhead
• The object is rarely modified and the existing Page Layout works fine

Dynamic Forms Migration Considerations

Migrating an existing Page Layout-based Lightning Page to Dynamic Forms is a one-way trip in practice. Salesforce provides a migration wizard that converts your existing Page Layout sections into Dynamic Forms Field Sections. Once migrated, you can refine the field placement, add conditional visibility, and customize sections — but reverting requires manual work.

The Decision Framework

When you have a UI requirement, the question isn’t “which feature do I use?” but “where in the layer stack does this requirement belong?” Use the interactive decision tool below to walk through a requirement and land on the right answer.

Real Scenarios with Right Answers

Theory is one thing — applying it to real work is another. Here are five common scenarios admins and BSAs face, with the right answer and reasoning for each.

Scenario 1: Field Visible Only on Closed-Won Opportunities

Requirement: Sales reps should see Commission Amount and Commission Date fields, but only on opportunities with Stage = “Closed Won.”

Right answer: Dynamic Forms with field-level visibility rules.

Why: This requires conditional field display based on record data. Page Layouts can’t do this — they’re static. Lightning Page component visibility rules can hide entire components but not individual fields. Dynamic Forms is the only layer that combines field-level granularity with conditional logic.

Scenario 2: Different Page Layout for Sales vs. Service

Requirement: Sales reps and Service agents should see entirely different field arrangements and related lists on the Account record.

Right answer: Two Lightning Page Variations, assigned by Profile.

Why: The difference is structural and tied to user role. Lightning Page Variations let you build distinct page experiences and assign them by App + Record Type + Profile combinations. Trying to do this with Dynamic Forms visibility rules would create a maintenance nightmare. Profile-based page assignment is the cleaner approach.

Scenario 3: Hide a Sensitive Field from Most Users

Requirement: Only Finance team members should see the Profit Margin field.

Right answer: Field-Level Security on the field itself, controlled via Profiles or Permission Sets.

Why: This is a security requirement, not a UI requirement. Hiding a field via Dynamic Forms or Page Layout doesn’t actually secure it — users can still access it via reports, list views, or APIs. Field-Level Security is the only layer that truly restricts access. UI configuration is for layout; security configuration is for access.

Scenario 4: Custom Button Not Showing on Lightning

Requirement: A custom button was added to the Page Layout but isn’t appearing on the Lightning record page.

Right answer: Verify the Highlights Panel component in Lightning App Builder is configured to inherit buttons from the Page Layout.

Why: Lightning Pages can use either the standard Highlights Panel (which inherits from Page Layout) or a custom Highlights Panel where buttons are configured separately. If the Lightning Page is using a custom variant, Page Layout buttons won’t appear. Check the Lightning App Builder configuration first.

Scenario 5: Mobile Users See Different Fields Than Desktop

Requirement: Field reps on mobile should see only the most critical fields; desktop users should see the full layout.

Right answer: Use Compact Layouts for mobile cards plus the Page Layout for full mobile rendering, while Lightning Page + Dynamic Forms drives desktop.

Why: Salesforce Mobile uses different rendering than desktop Lightning. Compact Layouts control the mobile card (the summary at the top of a record). Page Layouts drive the full mobile field display. Dynamic Forms support on mobile is limited as of Spring ’26. Build your mobile experience through Compact Layout + Page Layout, and your desktop experience through Lightning Page + Dynamic Forms — they’re parallel tracks, not competing ones.

Writing Better Functional Stories (For BSAs)

A common friction point between BSAs and admins is when functional stories specify the implementation instead of the requirement. A story that says “add Commission Amount to the Page Layout” assumes a specific UI layer — but that decision belongs to the admin, who knows the org’s architecture and conventions.

What to Specify, What to Leave Out

Bad Story vs. Good Story

The good story tells the admin what needs to happen and why, but leaves the how to the admin’s expertise. The admin can then choose: Dynamic Forms for the conditional visibility, Validation Rule for the required-on-stage logic, Field-Level Security for the profile-based access. That’s three different layers working together — and the admin knows which combination is right because they understand the org.

Common Story Anti-Patterns

Three patterns to avoid when writing functional stories:

Specifying the wrong layer. A story that says “add to Page Layout” when the org uses Dynamic Forms forces the admin into either ignoring the story’s literal text or doing extra work to translate it. Specify the outcome, not the implementation.

Mixing UI and security. A story like “hide this field from non-managers” mixes a security requirement with a UI request. The admin needs to know whether you mean “users can’t see this field anywhere” (security) or “this field doesn’t appear on this page for these users” (UI). Be explicit.

Underspecifying conditions. A story that says “show this field when relevant” without defining “relevant” forces the admin to either ask follow-up questions or guess. List the exact conditions: which field values, which user roles, which page types.

Common Pitfalls and How to Fix Them

Buttons Not Showing on Lightning Pages

Symptom: Added a button to the Page Layout, but it doesn’t appear on the Lightning record page.

Likely cause: The Lightning Page is using a custom Highlights Panel, or the Highlights Panel’s button configuration has been overridden in Lightning App Builder.

Fix: Open Lightning App Builder, click the Highlights Panel component, and verify it’s set to “Inherit from Page Layout.” If it’s been customized, you’ll need to add the button to the component’s button list directly.

Dynamic Forms Field Not Hiding

Symptom: Configured a visibility rule on a Dynamic Forms field, but it shows for users who shouldn’t see it.

Likely cause: The visibility rule is checking record data that the user has cached. Dynamic Forms re-evaluates rules when the record loads — if the underlying field has changed but the page hasn’t refreshed, stale data drives the visibility.

Fix: Refresh the page. If the issue persists, double-check the rule’s filter logic — common mistakes include using “equals” when you meant “not equals,” or leaving a default visibility of “always show” that overrides the conditional rule.

Wrong Lightning Page for Specific Profile

Symptom: A user with a specific Profile is seeing the wrong Lightning Page Variation.

Likely cause: The assignment hierarchy is matching a more general assignment before reaching the Profile-specific one. Salesforce checks “App + Record Type + Profile” first, but if that assignment doesn’t exist for the user’s exact combination, it falls back through the hierarchy.

Fix: In Lightning App Builder, click “Activation” on the Lightning Page, review the Assignments tab, and verify the user’s App + Record Type + Profile combination has an explicit assignment. If you want a Profile-specific page, you must assign it for every (App, Record Type) combination that user could be in — or use App Default with profile assignment.

Mobile Showing Different Fields Than Expected

Symptom: Configured fields via Dynamic Forms, but mobile users see the old Page Layout fields instead.

Likely cause: Salesforce Mobile uses Page Layout for full record rendering. Dynamic Forms is desktop-Lightning-first, with limited mobile support depending on the object and configuration.

Fix: If your Dynamic Forms field arrangement matters on mobile, check whether Dynamic Forms on Mobile is enabled for that object and your org. If not, you’ll need to maintain the Page Layout in parallel — adding/removing fields there for mobile users while Dynamic Forms drives desktop.

Required Field Validation Errors on Save

Symptom: A field is conditionally hidden via Dynamic Forms, but Salesforce throws a “field is required” error on save.

Likely cause: The field is marked “Required” at the field level (in object setup) or via Validation Rule. UI visibility doesn’t override required status — the field is still required even when hidden.

Fix: Either remove the universal required setting and use Validation Rule for conditional requiredness, or use Dynamic Forms to manage when the field is editable rather than hidden.

Exam Tips for Admin Cert Candidates

Frequently Asked Questions