Lightning App Builder Record Pages

1. Why Lightning App Builder Record Pages Matter
Record pages are the screens users live in every day: the Account, Case, Opportunity or custom object page where they read data, take actions and collaborate. In Lightning Experience, the layout and behaviour of these screens are controlled by Lightning Record Pages built in the Lightning App Builder. For the Advanced Administrator exam this topic sits inside the Advanced Objects and Applications domain and is tested heavily because it ties together page layouts, compact layouts, record types, profiles, apps, security, performance and declarative UI customisation. Expect scenario questions that ask you to pick the most appropriate declarative tool to achieve a user-interface requirement, and to understand how multiple tools interact (for example, which layer controls the Highlights Panel versus the Record Detail section).

2. What a Lightning Record Page Is
A Lightning Record Page is a FlexiPage (the underlying metadata type) that defines how a single record of an object is displayed in Lightning Experience and the Salesforce mobile app. The Lightning App Builder is the point-and-click tool used to create and edit these pages. The App Builder can build several page types:
• App Page – a home for an app, independent of any record.
• Home Page – the Lightning Home tab.
• Record Page – the focus of this guide; tied to one object.
• Email Application Pane and Embedded Service pages (less tested).

A record page is assembled from a template (regions such as header, main column, sidebar), standard components (Highlights Panel, Record Detail, Related Lists, Activities, Chatter, Path, Tabs, Accordion, Flow, Report Chart, List View, Rich Text, Visualforce, Related Record, Related List – Single, Dynamic Related List – Single, Related List Quick Links, Recent Items and others), custom components built with Lightning Web Components or Aura, and AppExchange components.

3. How It Works – Key Mechanics

3.1 Creating a page
From Setup go to Lightning App Builder or open the object in Object Manager > Lightning Record Pages, or simply click the gear icon on any record and choose Edit Page. You can clone the Salesforce default page or start from a blank template. When you choose a template you select the regions; you can later use Change Template and the builder maps components into the new regions where possible.

3.2 Activation and assignment (very frequently tested)
A page does nothing until it is activated. There are three levels of assignment and the most specific assignment always wins:
1. Org Default – applies to all users of the object unless overridden. You can set separate org defaults for Desktop and Phone form factors.
2. App Default – applies when the record is viewed inside a specific Lightning app, overriding the org default.
3. App, Record Type and Profile – the most granular; a page is shown only to users with a given profile, viewing a given record type, inside a given app. This overrides both app default and org default.
Rule of thumb: App + Record Type + Profile > App Default > Org Default. If a question says different teams or different record types need entirely different page structures, the answer is to build separate pages and assign them at the appropriate level. If only one or two components differ, use component visibility filters instead of a separate page.

3.3 Component visibility filters
Every standard and most custom components have a Set Component Visibility section. Filters can be based on:
• Record field values (including fields on related parent records via lookup traversal) – e.g., show a Rich Text warning only when Stage equals Closed Lost.
• User fields – e.g., Profile Name, Role, Country, custom user fields.
• Permissions – standard permissions and custom permissions.
• Device / form factor – Desktop or Phone.
Multiple conditions can be combined with AND / OR logic, up to ten filter conditions per component. Visibility filters hide the component visually; they are not a security control. Field-level security and object permissions still govern what data a user can actually access.

3.4 Record Detail versus Dynamic Forms
Traditionally the Record Detail component simply renders whatever the assigned page layout defines (sections, fields, field order, required and read-only flags on the layout). Dynamic Forms changes this: you break the record detail into Field Section components and individual Field components placed directly on the Lightning page. Benefits that the exam likes:
• Fields and sections can have their own visibility filters (e.g., show the Loss Reason section only when Stage = Closed Lost).
• Fields can be placed anywhere, including inside tabs or accordions, improving performance by loading fewer fields up front.
• You can set a field as required or read-only directly on the component.
• Fewer page layouts are needed because one Lightning page can adapt to many situations.
Dynamic Forms is enabled per page by clicking the Record Detail component and choosing Upgrade Now (migrates fields from the page layout) or by dragging Field Section components onto the page. It is supported for custom objects and the major standard objects (Account, Person Account, Contact, Opportunity, Lead, Case and more in recent releases) and can be enabled for the mobile app via a setting in the Record Detail or page properties. Fields from related objects (cross-object fields via lookup) can be shown read-only. Field-level security still applies; a universally required field must still be present when a record is created or edited through the page.

3.5 Dynamic Actions
By default the action buttons in the Highlights Panel come from the Salesforce Mobile and Lightning Experience Actions section of the page layout. With Dynamic Actions, enabled on the Highlights Panel component (Enable Dynamic Actions for desktop and optionally for mobile), you add actions directly in the App Builder and give each action its own visibility filters. This lets you show, for example, an Escalate action only to Support Managers or only when Status = New, without creating multiple page layouts.

3.6 What is still controlled outside the App Builder
Even with record pages, several things remain under other tools and exam questions test whether you know which tool to touch:
• Compact layout controls the fields shown in the Highlights Panel and in the mobile record header.
• Page layout controls the Record Detail fields (if not using Dynamic Forms), the related lists that appear in the Related Lists component, the actions (if not using Dynamic Actions), custom links and mobile cards.
• Field-level security and profiles / permission sets control access to data; the page cannot grant access.
• Record types determine which page layout and picklist values apply and can be a criterion for page assignment.

3.7 Useful standard components to recognise
• Related Lists – shows all related lists from the page layout.
• Related List – Single – one related list, chosen in the builder.
• Dynamic Related List – Single – a single related list where you choose the columns, add filters, sorting and a custom name directly in the builder, independent of the page layout.
• Related Record – displays and lets users edit fields of a related parent record (uses an update quick action to define fields).
• Related List Quick Links – compact links to related lists with hover previews.
• Path – requires Path to be set up and enabled for the object.
• Flow – embeds a screen flow; you can pass the recordId automatically.
• Report Chart, List View, Rich Text, Visualforce (page must be enabled for Lightning and can accept the record via standard controller).
• Tabs and Accordion – containers that improve performance because content in non-active tabs loads lazily.
• Chatter and Activities – standard collaboration and timeline components.
• Record Detail and Highlights Panel – discussed above.

3.8 Form factors and the mobile app
A page can be built for Desktop, Phone or Desktop and Phone. You can preview in the builder using the form-factor switcher, assign different pages as org default per form factor, or keep one page and use device-based visibility filters. Components that are not mobile-compatible are flagged in the builder.

3.9 Performance analysis
The Analyze button in the App Builder runs a page performance analysis. It flags issues such as too many fields in the record detail, too many components in the first visible area, components that are slow to load and recommends moving content into tabs or accordions, reducing fields visible on load, and using Dynamic Forms. When a scenario mentions slow record pages, the correct admin response is Page Analysis plus restructuring with tabs, accordions and Dynamic Forms – not adding more components or buying more licences.

3.10 Deployment and console considerations
Record pages are FlexiPage metadata and can be deployed via change sets, packages or metadata API. Pinned-region templates (Pinned Header, Pinned Left Sidebar, etc.) are designed for Lightning console apps so that key components stay visible as the user switches sub-tabs. Lightning pages assigned to a console app behave the same regarding assignment hierarchy.

4. How to Approach Exam Questions on This Topic
Most questions describe a business requirement and ask for the best declarative solution. Work through this decision flow:
• Does the requirement affect fields in the Highlights Panel? Think compact layout.
• Does it affect which fields appear in the record detail for everyone? Think page layout or Dynamic Forms.
• Does it require fields or sections to appear only under certain conditions? Think Dynamic Forms with visibility filters.
• Does it require a component shown only to certain users, devices or record states? Think component visibility filters.
• Does it require action buttons that change with record state or user? Think Dynamic Actions.
• Does it require completely different page structures for different apps, profiles or record types? Think separate record pages assigned by App, Record Type and Profile.
• Does it involve filtering or choosing columns on a related list directly on the page? Think Dynamic Related List – Single.
• Does it involve slow loading? Think Page Analysis, tabs, accordions, fewer components and fields.
• Does it involve guided data entry or a process on the record? Think Flow component or Path.
• Does it involve hiding data for security reasons? The page is never the answer – use field-level security, sharing or permissions.

5. Exam Tips: Answering Questions on Lightning App Builder Record Pages
• Memorise the assignment hierarchy: App + Record Type + Profile beats App Default, which beats Org Default. If a question says a page is activated as org default but a group of users sees something different, look for an app-level or profile-level assignment.
• One page, many behaviours: Salesforce prefers fewer pages with visibility filters and Dynamic Forms over many near-duplicate pages. If an answer option reduces maintenance while meeting the requirement, it is usually correct.
• Visibility is not security: any answer that uses component visibility, Dynamic Forms or page assignment to secure sensitive data is wrong. Pick field-level security or permission sets.
• Know what each layer controls: compact layout = Highlights Panel fields; page layout = record detail fields, related lists and actions (unless Dynamic Forms / Dynamic Actions are used); Lightning page = arrangement of components and conditional display.
• Dynamic Forms keywords: conditional sections, fields in tabs, fewer page layouts, Upgrade Now, Field Section component, mobile support must be enabled.
• Dynamic Actions keywords: actions based on field values or user attributes, enabled on the Highlights Panel, replaces the page layout action list for that page.
• Performance keywords: Analyze button, too many fields, move to tabs or accordions, reduce components above the fold.
• Form factor keywords: Phone versus Desktop org defaults, device-based visibility filters, mobile-compatible components.
• Remember the prerequisites: Path must be enabled before the Path component works; a Visualforce page must be Lightning-enabled; a flow must be a screen flow to be embedded; a custom component must be exposed to record pages in its metadata to appear in the builder.
• Eliminate code answers: if a requirement can be met declaratively with App Builder features, the exam expects the declarative option over Apex, LWC or Visualforce.
• Watch for record type and profile wording: if the scenario mentions a specific record type or profile needing a different experience, the answer almost always involves page assignment at the App, Record Type and Profile level or visibility filters using record type / profile criteria.
• Deployment questions: Lightning pages (FlexiPages) move via change sets or packages; page assignments and the related page layouts, record types and components must also be included or already exist in the target org.

6. Quick Summary
Lightning App Builder Record Pages define the Lightning Experience and mobile view of a record. They are built from templates and components, activated through a three-level assignment hierarchy, and made adaptive through component visibility filters, Dynamic Forms, Dynamic Actions and Dynamic Related Lists. They work alongside, not instead of, page layouts, compact layouts, record types and security settings. On the exam, identify which layer the requirement touches, favour the simplest declarative tool that minimises page and layout sprawl, and never confuse presentation controls with data security.