13.1 Composing UI in Lightning Apps

13.1 Composing UI in Lightning Apps

Quick Answer: In Lightning Experience, you compose most UI with Lightning App Builder on flexipages—record pages, home pages, and app pages—plus tabs, the utility bar, and optional Dynamic Forms/Actions. Expose LWC (or Aura) with the right targets/interfaces so admins can place them; embed Visualforce only when needed. Design composition for desktop and mobile, not one fixed layout.

Chapters 11–12 covered building Visualforce and Lightning components. This section covers assembling those pieces into the apps users actually open—core User Interface (≈25%) judgment on Platform Developer I.

What “Composition” Means on the Lightning Platform

Salesforce separates component development from page composition:

Exam stems often ask: Where do you put this? Which page type? Which target?—not how to write SOQL inside a button handler.

Lightning App Builder and Flexipages

Lightning App Builder is the drag-and-drop tool for Lightning pages. Under the hood, those pages are Lightning page metadata—commonly called flexipages (FlexiPage in metadata API terms).

A flexipage defines:

• Page type (record, app, home, and related variants)
• Template / regions (header, main, sidebar, etc.)
• Components in each region and their properties
• Optional form factor and visibility rules

Developer implication: Your custom component only appears in App Builder if it is exposed and targeted correctly (LWC js-meta.xml; Aura implements + design resource).

Page types you must distinguish

Exam trap: Putting a component that requires recordId only on a home or generic app page without wiring an ID will fail or show empty state. Conversely, home-page widgets should not assume a current record.

Assigning pages

After building a record page, admins activate it and assign by app, record type, and profile (and sometimes form factor). Multiple record pages can exist for the same object; activation rules decide who sees which layout. Developers should not hard-code “everyone uses the same page” assumptions in training scenarios.

Dynamic Forms and Dynamic Actions (Overview)

Dynamic Forms move many fields off the classic “single Record Detail” blob into Field sections on the Lightning record page. Benefits the exam associates with Dynamic Forms:

• Place fields in flexible regions beside custom components
• Visibility rules (for example, show a section only when Stage = Closed Won)
• Better progressive disclosure without a full custom LWC form

Dynamic Actions move standard and custom actions (buttons/menu items) onto the Highlights Panel (and related action areas) with visibility filters—so “Submit for Approval” appears only when criteria match.

Developer takeaway:

• Prefer Dynamic Forms/Actions + App Builder when the need is field layout and conditional standard actions
• Prefer LWC when you need multi-object wizards, complex client interaction, or non-field UI the page cannot express
• Custom components and Dynamic Forms coexist on the same record page

You are not expected to recite every Dynamic Forms limitation per release, but you should recognize them as declarative composition tools that reduce custom UI code.

Tabs, Lightning Apps, and the Utility Bar

Lightning apps

A Lightning app groups navigation, branding, and (optionally) a utility bar. Users switch apps from the App Launcher. Composition decisions often start with “which app is this for?” because record page activation and default landing can be app-specific.

Tabs

Tabs surface objects, Visualforce pages, Lightning pages (app pages), Lightning components, and web tabs in the app’s navigation bar. Patterns:

• Object tab → standard list/recent for that object
• Lightning page tab → opens an app page flexipage
• Lightning component tab → hosts a single component as the “page”
• Visualforce tab → hosts a VF page in Lightning chrome

Exam heuristic: For a custom multi-widget workspace, create an app page in App Builder and add a Lightning page tab. For a single focused LWC tool, a component tab can be enough.

Utility bar

The utility bar docks persistent tools at the bottom of a Lightning app (notes, history, custom LWC/Aura utilities). Components need the correct utility target/interface (for example LWC lightning__UtilityBar) and should tolerate narrow width and open/close lifecycle.

Utility items are ideal for:

• Always-available calculators, timers, or softphone-like tools
• Context-aware helpers that read the current record when the API allows
• Lightweight UI that should not consume main page real estate

Placing LWC, Aura, and Visualforce on Pages

Lightning Web Components

Expose for App Builder with js-meta.xml:

<isExposed>true</isExposed>
<targets>
    <target>lightning__RecordPage</target>
    <target>lightning__AppPage</target>
    <target>lightning__HomePage</target>
    <target>lightning__UtilityBar</target>
</targets>

• lightning__RecordPage — record pages; pair with @api recordId (and often objectApiName)
• lightning__AppPage / lightning__HomePage — non-record composition
• lightning__UtilityBar — utility items
• Other targets (Flow screens, communities/Experience Cloud, etc.) appear in broader platform work; PDI stresses core LEX page targets

Use targetConfigs / properties so admins set titles, record filters, or boolean flags without code changes.

Aura components

Aura uses implements interfaces such as:

• flexipage:availableForRecordHome + force:hasRecordId for record pages
• flexipage:availableForAllPageTypes (broader availability)
• Utility-specific interfaces for utility bar placement

The design resource exposes attributes in App Builder (Chapter 12).

Visualforce on Lightning pages

You can drop a Visualforce component (page host) onto a Lightning page or open VF via tabs/actions. Remember:

• VF runs in a more isolated container than LWC on the same page
• Styling may need lightningStylesheets (Chapter 11)
• Navigation and events do not freely merge with surrounding LWC without intentional patterns
• For new App Builder widgets, default recommendation remains LWC

Composition decision table

Navigation in Lightning Experience (Developer-Relevant)

Users move through:

1. App Launcher → Lightning app
2. Navigation bar tabs → objects, pages, components
3. Record pages → related lists, subtabs (especially in console apps)
4. Actions → modals, quick actions, Dynamic Actions
5. Utility bar → docked tools

In LWC, programmatic navigation uses APIs such as NavigationMixin (lightning/navigation) with page references (record page, object page, named page, web page, and so on). Exam-level awareness:

• Prefer platform navigation APIs over hard-coded /lightning/r/... string hacks when teaching “correct” patterns
• Quick actions and overrides can open LWC, Aura, VF, or flows—choose the host that matches the UI technology
• Console vs standard navigation changes tabbing behavior; components should not assume a single browser tab equals a single record workspace

You do not need every NavigationMixin type memorized, but you should know developers navigate via platform navigation services, while admins compose primary destinations via apps/tabs/pages.

Mobile Considerations (High Level for Developers)

Salesforce mobile app and responsive desktop share Lightning components, but form factors differ:

Exam framing: “Works in Lightning Experience on desktop and mobile” → Lightning components on flexipages with responsive design, not a Classic-only VF page with fixed widths.

End-to-End Composition Checklist

1. Choose page type (record / home / app) and app ownership
2. Prefer standard components + Dynamic Forms/Actions before custom code
3. Build LWC with correct targets and @api properties
4. Place components in regions; set visibility by criteria/form factor
5. Wire tabs and utility bar for navigation and persistent tools
6. Activate/assign record pages by app, record type, profile
7. Validate mobile form factor and empty states when recordId is absent

Bottom line: Platform Developer I expects you to compose Lightning apps with App Builder flexipages, know record vs home vs app pages, expose LWC/Aura correctly, use tabs and the utility bar, apply Dynamic Forms/Actions when declarative layout suffices, embed VF only when justified, and keep navigation and mobile form factors in mind when designing custom UI.