Topic guide

Record types, page layouts, and Lightning pages.

Updated August 30, 2026.

Many Salesforce Administrator configuration questions are solved by identifying which layer controls the change: business process, picklist values, layout, actions, components, visible fields, or experience by app and device. This guide helps you separate record types, page layouts, Lightning pages, Dynamic Forms, and compact layouts.

The mental model: process, data, and experience

When a question says users need to "see a different page", do not immediately answer with Lightning App Builder. First decide what different means. Maybe they need different picklist values because they follow different business processes. Maybe they need different fields, buttons, or related lists. Maybe they need components in another position, conditional visibility, or a different experience by app, profile, record type, or form factor.

Salesforce splits those responsibilities across several tools. Record types separate processes and available values. Page layouts control many parts of the traditional record detail experience. Lightning App Builder organizes components and activates pages by context. Dynamic Forms lets you control fields more granularly inside Lightning App Builder. Compact layouts control key fields in the highlights panel and other compact views.

Practical rule: if the process or picklists change, think record type; if actions, related lists, or the traditional detail block change, think page layout; if components and regions change, think Lightning page.

Record types

Record types let you offer different business processes, picklist values, and page assignments for the same object. They are useful when one object represents scenarios with different behavior. For example, new business and renewal opportunities can have different stages; technical cases and billing cases can have different statuses; partner accounts and customer accounts can require different layouts.

A record type is not just a nice label. It affects which values the user can choose, which process applies, and which page layout the user can see based on profile. That is why you should not create record types for every minor variation. If you only need to hide a field for certain users, field-level security, Dynamic Forms, or a page layout may be enough. If you need to separate processes and picklists, record type makes more sense.

In exam questions, look for phrases like different sales processes, different support processes, different picklist values, different page layouts by process, or same object used for multiple business processes. Those usually point to record types. If the question only asks to show an extra component for users in one app, it probably points toward Lightning App Builder.

Page layouts

Page layouts control many elements that appear on a record page: fields inside the traditional Record Detail component, sections, related lists, buttons, links, and actions. They also participate in assignment by profile and record type. If an org uses record types, the combination of profile and record type determines which page layout a user sees.

Page layout is not absolute security. Removing a field from a layout does not necessarily block access to the field everywhere. For field security, think field-level security. Page layout can make fields required or read-only in the interface, but if the question talks about consistently preventing access to sensitive data, field-level security may be more correct.

On the exam, page layout is usually a candidate when the scenario mentions fields on the page, related lists, buttons, actions, sections, assignment by profile and record type, or inline edit behavior. If a question says two profiles should see different related lists on the same object, page layout may be enough. If it says they should see different Lightning components by app or device, look at Lightning pages.

Lightning pages and Lightning App Builder

Lightning pages are pages made of components arranged in regions. Lightning App Builder lets you change structure, tabs, standard components, custom components, and component visibility. It also lets you activate pages for combinations of app, record type, profile, and form factor, depending on the page type and available configuration.

The major difference from page layout is that Lightning App Builder controls the Lightning experience: where components appear, which sections exist, which components display in a context, and how the page is organized. Page layout can still control fields if the page uses the Record Detail component, along with traditional actions and related lists.

If the question mentions rearrange components, show a component only when a field has a value, assign a page to an app, optimize phone versus desktop, add a custom Lightning component, or create a custom record page, Lightning App Builder is a strong candidate. If it mentions changing traditional related list columns or assigning layout by profile and record type, page layout remains relevant.

Dynamic Forms and conditional visibility

Dynamic Forms lets you place fields and sections as individual components inside Lightning App Builder, instead of relying on one full Record Detail block. This enables more granular conditional visibility: showing a field when another field has a value, separating sections by context, or reducing noise for users who do not need to see everything.

Dynamic Forms does not replace every concept. Field-level security still controls data security. Page layouts can still affect actions, related lists, and parts of the experience. Record types still separate processes and picklist values. Dynamic Forms is especially useful when the question asks to show or hide fields on a Lightning page based on conditions without creating many duplicated layouts.

The trap is using Dynamic Forms to solve business process. If the problem is that two opportunity types need different stages, hiding fields is not enough. That points to record type and sales process. If the problem is that a field should only appear when Stage is Closed Lost, Dynamic Forms or component visibility may be the better answer.

Compact layouts, highlights, and actions

Compact layouts determine the key fields that appear in the highlights panel and other compact views, such as lookup previews or cards. They matter because they help users recognize a record quickly without opening every detail. In Lightning Experience, the first fields in the compact layout have special visibility in the record header.

Do not confuse compact layout with page layout. If the question asks to control the main fields shown at the top of the record page or in a compact card, compact layout is a candidate. If it asks to reorganize all detail fields, think page layout or Dynamic Forms. If it asks to show primary actions in the header, page layout and Dynamic Actions may appear depending on the context.

Actions also generate questions. Object-specific actions use record context; global actions are broader. Dynamic Actions let admins control Lightning actions more flexibly when the configuration supports it. If the question asks for an action to appear only under certain conditions in Lightning, do not automatically answer page layout; check whether Dynamic Actions fits better.

Common mistakes when studying page configuration

The first mistake is creating record types for everything. If you only want to hide or show fields, you probably do not need to separate processes. Record types have maintenance cost because they affect picklists, assignments, automation, reports, and user experience. Use them when there is a real process or value difference.

The second mistake is confusing layout with security. A field missing from the layout is not necessarily a protected field. If a question says certain users must never see salary, margin, or sensitive data, field-level security usually matters more. The third mistake is forgetting that Lightning pages and page layouts can work together: the Lightning page may contain a Record Detail component that still gets fields from the page layout.

The fourth mistake is reading "different page" without identifying the cause. If the object and relationships change, think Object Manager. If values change by process, think record type. If the traditional detail changes, think page layout. If components, visibility, app, or device change, think Lightning App Builder. If the compact header changes, think compact layout.

Quick decision checklist:

  • Is the difference about process, picklists, fields, actions, or components?
  • Does the need depend on profile, record type, app, or device?
  • Does the page use traditional Record Detail or Dynamic Forms?
  • Is the requirement visual experience or data security?
  • Does the solution reduce duplication or create unnecessary maintenance?

Official resources and practice

To practice this topic, take an object such as Opportunity and design two processes: new business and renewal. Define which picklists change, which record types you need, which layouts apply by profile, which components belong on the Lightning page, and which fields deserve Dynamic Forms. Then practice questions by underlining words like process, picklist, layout, component, visibility, profile, and record type.

BlueForce is not affiliated with Salesforce. This guide is original editorial content based on study experience, public objectives, and official resources.