ExamFinch.com My Study

Study guide

13.1 Composing UI in Lightning Apps

Practice this exam

Salesforce Certified Platform Developer I Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Blueprint Weights & Study Strategy

2 Platform Fundamentals

2.1 Multi-Tenant Architecture & Shared Resources 2.2 MVC Mapping on the Lightning Platform 2.3 Declarative vs Programmatic Decisions 2.4 Agentforce for Developers: Use Cases & Limitations

3 Data Modeling & Schema

3.1 Objects, Fields & Schema Design 3.2 Relationship Types & Implications 3.3 Schema Design Impact on Apex 3.4 Data Import & Export for Development

4 Platform Data Features

4.1 Formula Fields & Roll-Up Summaries 4.2 Core CRM Objects & Standard Schema 4.3 AppExchange Extensions & Platform Boundaries

5 Declarative Process Automation

5.1 Record-Triggered Flows & Declarative Automation 5.2 Approval Processes & Business Rules 5.3 When to Use Apex vs Declarative Tools

6 Apex Language Basics

6.1 Variables, Constants & Apex Data Types 6.2 Lists, Sets & Maps 6.3 Control Flow & Exception Handling 6.4 Classes, Interfaces & OOP Patterns

7 SOQL, SOSL & DML

7.1 SOQL Query Fundamentals 7.2 SOSL Search Fundamentals 7.3 DML Operations & Bulkification 7.4 Governor Limits & Transaction Boundaries

8 Apex Triggers & Order of Execution

8.1 Trigger Structure & Context Variables 8.2 Bulk Trigger Patterns & Best Practices 8.3 Save Order of Execution 8.4 Recursion, Cascading & Transaction Control

9 Asynchronous Apex

9.1 @future Methods 9.2 Queueable Apex 9.3 Batch Apex 9.4 Schedulable Apex & Job Orchestration

10 Security, Events & Schema Access

10.1 Sharing, FLS, CRUD & Injection Prevention 10.2 Platform Events Publish & Subscribe 10.3 Programmatic Schema Access (Describe)

11 Visualforce

11.1 Visualforce Pages & Markup 11.2 Standard, Custom Controllers & Extensions 11.3 Visualforce in Lightning Experience

12 Lightning Components

12.1 Lightning Component Framework Benefits 12.2 Aura Component Structure & Resources 12.3 Lightning Web Components Fundamentals 12.4 LWC Data Access: Wire, Imperative & Events

13 UI Composition & Apex Integration Patterns

13.1 Composing UI in Lightning Apps 13.2 UI Security, Performance & Accessibility Patterns 13.3 Apex Actions for Flow, LWC, and Agentforce

14 Apex Testing

14.1 Testing Framework & Coverage Requirements 14.2 Writing Unit Tests for Triggers & Classes 14.3 Test Data Strategies & Isolation 14.4 Executing Tests & Execute Anonymous Differences

15 Debugging & Developer Tools

15.1 Debug Logs & Monitoring 15.2 Developer Console, CLI, VS Code & Workbench 15.3 Sandboxes, Scratch Orgs & Environment Strategy

16 Deployment & Release

16.1 Change Sets & Metadata Deployment 16.2 Unlocked Packages, Metadata API & Salesforce DX 16.3 Release Readiness & Credential Maintenance

13.1 Composing UI in Lightning Apps

Key Takeaways Explain This Topic AI

Lightning App Builder composes flexipages—record, home, and app pages—from standard and custom components without writing page-level Apex

Expose LWC with isExposed and targets (and Aura with implements/design) so components appear on the correct page types and utility bar

Dynamic Forms and Dynamic Actions let admins control field/action visibility by record type, criteria, and form factor; developers still supply custom widgets when declarative UI is insufficient

Tabs, Lightning apps, and the utility bar define navigation and persistent tools; Visualforce can embed on Lightning pages but LWC is preferred for new composition

Design for Lightning Experience and Salesforce mobile: responsive layouts, form-factor visibility, and avoid desktop-only assumptions in custom components

Last updated: August 2026

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 :

  • Layer Who owns it Examples
  • Component Developer (and some standard components) LWC, Aura, standard related lists, Highlights Panel
  • Page / flexipage Admin or developer via App Builder / metadata Record page for Account, Sales app home
  • App & navigation Admin / app builder Lightning App, tabs, utility bar items

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

  • Page type Typical use Context passed to components
  • Record page Object detail/edit workspace for one record recordId , object API name context

Home page Landing experience for an app or org home No single record; often charts, list views, custom dashboards widgets

App page Custom workspace not tied to one record (console-like or utility screens) No standard recordId unless you pass one

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
  • Requirement Prefer
  • Arrange standard + custom cards on Account Record page + LWC/standard components
  • Sales landing with charts and list views Home page or app page
  • Custom workspace with multiple regions App page + tab
  • Persistent helper across all pages in an app Utility bar component
  • Legacy VF still required VF tab or VF component on flexipage; plan LWC migration
  • Field layout by record type/criteria Dynamic Forms first
  • Navigation in Lightning Experience (Developer-Relevant)

Users move through:

  • App Launcher → Lightning app
  • Navigation bar tabs → objects, pages, components
  • Record pages → related lists, subtabs (especially in console apps)
  • Actions → modals, quick actions, Dynamic Actions
  • 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:

  • Concern Guidance
  • Form factor visibility In App Builder, show/hide components for desktop vs phone
  • Layout density Stack regions; avoid wide multi-column custom HTML tables
  • Base components / SLDS Prefer responsive base Lightning components over fixed-pixel CSS
  • Utility and actions Prioritize critical actions; mobile real estate is scarce
  • Performance Mobile networks amplify chatty Apex and heavy initial payloads (see 13.2)
  • Unsupported desktop-only features Some VF or browser plugins fail on mobile—test critical paths

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
  • Choose page type (record / home / app) and app ownership
  • Prefer standard components + Dynamic Forms/Actions before custom code
  • Build LWC with correct targets and @api properties
  • Place components in regions ; set visibility by criteria/form factor
  • Wire tabs and utility bar for navigation and persistent tools
  • Activate/assign record pages by app, record type, profile
  • 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.