Standard Lightning Page Components and Visibility Rules

Why This Topic Matters

Lightning pages are the user interface of modern Salesforce. Every record a sales rep opens, every Home page a service agent lands on, and every app page an executive uses is assembled in the Lightning App Builder from components. The Advanced Administrator exam tests this topic inside the Advanced Objects and Applications domain because it sits at the intersection of user experience, declarative customization and security-adjacent design decisions. An advanced admin is expected to deliver tailored experiences for different roles, devices and record states without writing code and without creating an unmanageable number of page layouts, record types and profiles. Component visibility rules are the primary tool for doing exactly that.

In practice, misunderstanding this area leads to real problems: admins build five near-identical record pages when one page with visibility filters would do, or they assume hiding a component protects data when it does not. The exam probes both of those misconceptions.

What Lightning Pages and Standard Components Are

A Lightning page is a custom layout built in the Lightning App Builder. There are several types:
• Record Page – displays a single record of a specific object (Account, Case, custom object, etc.).
• App Page – a general-purpose page added to an app's navigation, often used for dashboards or productivity hubs.
• Home Page – the landing page for an app, assignable per app and profile.
• Embedded Service Page and other specialized types for specific features.

Each page is built on a template (for example, Header and Right Sidebar, or Three Regions) that defines regions. Into those regions you drag components. Components come in three flavors:
• Standard components – built and maintained by Salesforce, available out of the box.
• Custom components – Lightning Web Components or Aura components built by developers.
• AppExchange components – installed from managed packages.

The exam focuses on the standard set. The most frequently referenced ones are:

Record-centric components
• Highlights Panel – shows the key fields from the compact layout and the record's quick actions. With Dynamic Actions enabled, actions can be assigned directly on the component with their own visibility filters, bypassing the page layout.
• Record Detail – renders the fields and sections defined on the assigned page layout.
• Field Section and Field components – used with Dynamic Forms. Instead of a single Record Detail block, fields are placed individually or in sections directly on the Lightning page, and each section or field can carry its own visibility rule.
• Related Lists – shows all related lists from the page layout.
• Related List – Single – displays one chosen related list.
• Dynamic Related List – Single – a related list configured entirely on the Lightning page (columns, filters, sort, actions) with no dependency on the page layout.
• Related List Quick Links – compact hover links to related lists.
• Related Record – displays and lets users edit fields of a parent or lookup record (for example, the Account on a Case) using a quick action layout.
• Path – the guided sales or service path tied to a picklist such as Stage or Status.
• Activities and Chatter – activity timeline and feed.
• Potential Duplicates – surfaces duplicate rule matches.

Layout and container components
• Tabs – groups components into tabs; each tab can have its own visibility filter.
• Accordion – collapsible sections for organizing content vertically.

Content and analytics components
• Rich Text – formatted text, instructions or banners.
• Report Chart and Dashboard – embed analytics; Report Chart can be filtered by the current record.
• List View – shows a list view of any object.
• Recent Items, Today's Events, Today's Tasks, Assistant, Key Deals, Recommendations, Einstein Next Best Action – productivity and guidance widgets, mostly for Home pages.
• Flow – embeds a screen flow; on a record page the record ID can be passed into a flow variable automatically.
• Visualforce – embeds a Visualforce page that is enabled for Lightning.

How Page Assignment Works

Once built, a page must be activated. Record pages can be assigned at three levels, from broadest to most specific:
1. Org Default – applies everywhere unless overridden.
2. App Default – applies within a specific Lightning app.
3. App, Record Type and Profile – the most granular assignment.

The most specific assignment wins. Home pages can be assigned as org default or by app and profile. App pages are activated by adding them to app navigation. Record pages can also be assigned separately by form factor (desktop versus phone), so you can have a different page for mobile users.

Knowing this hierarchy is critical because many exam scenarios can be solved either by a separate page assignment or by a visibility rule on a shared page. The exam wants you to choose the simplest maintainable option.

What Component Visibility Rules Are

A component visibility rule (set under Set Component Visibility in the component properties panel) defines one or more filters that must be true for a component to render. If no filter is defined, the component is always visible. Filters are combined with AND logic: all filters must be true for the component to show. You can add up to 10 filters per component.

There are three main filter sources:

1. Record Field (record pages only) – compares a field on the current record to a value. Example: show the Discount Approval Rich Text component only when Discount Percent is greater than 20. You can traverse to parent fields, for example Account > Industry on an Opportunity page. Formula fields and most data types are supported; you compare using operators such as Equal, Not Equal, Contains, Greater Than.

2. User – evaluates fields on the running user record, such as Profile Name, Role Name, User Type, Department or any custom field on User. Example: show a Report Chart only when the user's Profile Name equals Sales Manager.

3. Device – evaluates the form factor through $Client.formFactor, allowing you to show a component only on Desktop or only on Phone. This is ideal for hiding heavy components from mobile users while keeping a single page.

4. Permission – evaluates whether the user has a specific standard or custom permission, for example $Permission.CustomPermission.View_Financials. This is the recommended approach when the requirement is tied to a capability rather than to a profile name, because permissions can be granted via permission sets and are not broken when profiles are renamed or consolidated.

Visibility rules apply to individual components, to individual tabs inside a Tabs component, to Field Sections and individual Fields in Dynamic Forms, and to Dynamic Actions in the Highlights Panel. They are available on record pages, app pages and Home pages, but record field filters are only available on record pages because there is no record context elsewhere.

How Visibility Rules Behave at Runtime

• Filters are evaluated when the page loads and, for record field filters, re-evaluated when the record is updated in the browser. If a user changes Stage to Closed Won and saves, a component filtered on that value appears or disappears immediately without a full page refresh.
• A component hidden by a visibility rule does not render, so it is not shown to the user. Hiding components can improve perceived performance by reducing what loads for users who do not need it.
• Visibility rules are not a security mechanism. They control presentation only. If a user has field-level security access to a field, they can still see it through reports, list views, the API, or another page. Real data protection must come from field-level security, object permissions and sharing settings. The exam frequently tests this distinction.
• Field-level security still governs what a component can display. If a component is visible but the user lacks read access to a field it shows, the field simply does not appear.

Dynamic Forms: Field-Level Visibility

Dynamic Forms extend visibility rules down to fields. Rather than relying on the Record Detail component and multiple page layouts, you upgrade the record page to Dynamic Forms, which breaks the layout into Field Sections you place directly on the canvas. You can then:
• Place different sections in different tabs or columns.
• Set visibility filters on an entire section (for example, show the Shipping Details section only when Requires Shipping is true).
• Set visibility filters on a single field.
• Mark fields as required or read-only on the page.

Dynamic Forms are available on custom objects and on many standard objects, and they let you reduce the number of page layouts and record types needed. A classic exam pattern is: The company has six page layouts that differ only in which sections appear for certain record statuses. How can the admin simplify? The answer is Dynamic Forms with section-level visibility rules on a single page.

Putting It Together: Design Decision Framework

When faced with a requirement, ask these questions in order:
1. Does the difference depend on the record's data? Use a record field visibility filter (or a Dynamic Forms section filter). Do not create new record types or page layouts just to vary visibility by field value.
2. Does it depend on who the user is? If it is tied to a capability, use a Permission filter with a custom permission. If it is tied to profile or role and the page is otherwise identical, use a User filter. If the entire page differs substantially by profile, assign separate pages at the app, record type and profile level.
3. Does it depend on the device? Use a Device filter on the component, or assign a separate mobile page by form factor if the whole experience differs.
4. Does it depend on the app context? Use App Default page assignment or separate Home pages per app.
5. Is the real requirement to protect data? Then visibility rules are the wrong answer; adjust field-level security or sharing.

Exam Tips: Answering Questions on Standard Lightning Page Components and Visibility Rules

Tip 1 – Translate keywords into filter types. Phrases like only when the Stage is Closed Won, once the Case is escalated or if the Amount exceeds point to a Record Field filter. Only for Sales Managers or users in the Finance department point to a User filter. Users who have been granted or only users with permission to point to a Permission filter. Mobile users, on their phones or on desktop only point to a Device filter.

Tip 2 – Favor one page with visibility rules over many pages. When answer options include creating additional page layouts, record types or Lightning pages versus adding a visibility filter to a component on an existing page, the visibility filter is almost always the intended answer if the pages are otherwise identical. The exam rewards minimizing maintenance.

Tip 3 – Know when separate page assignment IS the right answer. If the question describes two groups needing substantially different pages (different templates, completely different component sets, different Home pages per app), assignment by app, record type and profile or per-app Home page assignment is correct. Watch for the words app, record type and profile appearing together.

Tip 4 – Remember the three-tier assignment hierarchy. Org Default is overridden by App Default, which is overridden by App + Record Type + Profile. If a question asks why a user sees a different page than expected, look for a more specific assignment.

Tip 5 – Visibility is not security. If a question asks how to prevent users from seeing or accessing sensitive data, choose field-level security, object permissions or sharing rules, not component visibility. If the question asks to declutter, simplify or show relevant information, visibility rules are appropriate.

Tip 6 – Record field filters only work on record pages. If a question mentions a Home page or App page and a field-based condition, recognize that record field filters are unavailable there; only User, Device and Permission filters apply.

Tip 7 – Filters use AND logic. If a requirement says a component should show when either condition A or condition B is true, you cannot express that directly with multiple filters. The common solution is a formula field on the record that resolves the OR logic to a single checkbox or text value, then filter on that one field.

Tip 8 – Dynamic Forms for field and section visibility. When the requirement is to show or hide specific fields or sections rather than whole components, the answer is Dynamic Forms with visibility rules on Field Sections or Fields. Recognize phrases such as reduce the number of page layouts or show additional fields only when.

Tip 9 – Dynamic Actions for action visibility. If the question is about showing a quick action button only under certain conditions (for example, Submit for Approval only when Status is Draft), the answer is enabling Dynamic Actions on the Highlights Panel and setting a visibility filter on the action, not creating multiple page layouts.

Tip 10 – Match the component to the need. Embed a screen flow → Flow component. Show one related list with custom columns and filters not controlled by the page layout → Dynamic Related List – Single. Show and edit parent record fields → Related Record. Show a chart filtered to the current record → Report Chart. Display instructions or warnings → Rich Text (often paired with a visibility rule). Organize many components in limited space → Tabs or Accordion.

Tip 11 – Prefer custom permissions over profile names. If two answers both work but one filters on Profile Name and the other on a custom permission assigned via permission set, the custom permission is the more scalable, best-practice choice and is usually what the exam expects.

Tip 12 – Eliminate code-based answers. If a declarative option (standard component plus visibility rule or Dynamic Forms) satisfies the requirement, options involving Apex, Lightning Web Components or Visualforce are distractors on an administrator exam.

Quick Review Checklist
• Lightning App Builder builds Record, App and Home pages from templates and components.
• Standard components include Highlights Panel, Record Detail, Related Lists, Related List – Single, Dynamic Related List – Single, Related Record, Path, Activities, Chatter, Tabs, Accordion, Rich Text, Report Chart, Dashboard, List View, Flow, Visualforce and more.
• Page assignment hierarchy: Org Default → App Default → App + Record Type + Profile; form factor can also drive assignment.
• Visibility filters: Record Field (record pages only), User, Device, Permission; up to 10 per component; combined with AND.
• Visibility applies to components, tabs, Dynamic Forms sections and fields, and Dynamic Actions.
• Visibility rules re-evaluate on record change without a page reload.
• Visibility is presentation, not security; FLS and sharing protect data.
• Use formula fields to achieve OR logic; use custom permissions for capability-based visibility.

Master these concepts and you will be able to read any scenario on the exam, identify the governing requirement, and select the most efficient declarative solution with confidence.