Lightning App Builder
Lightning App Builder is Salesforce's drag-and-drop tool for designing Lightning Experience pages without writing code.
Definition
Lightning App Builder is Salesforce's drag-and-drop tool for designing Lightning Experience pages without writing code. It is the canvas where admins assemble Record Pages (the detail view for each sObject), App Pages (custom landing pages), Home Pages (the user dashboard), and Embedded Service pages. Each page is built from Lightning Components, both standard (provided by Salesforce) and custom (built with Lightning Web Components or Aura).
The App Builder transformed Salesforce page design when Lightning Experience launched in 2015. Where the classic UI used static page layouts with fixed sections, Lightning record pages built in App Builder can show different components to different users, react to record state, place fields anywhere on the page (via Dynamic Forms), and combine Salesforce-standard with custom components freely. App Builder is the foundation of every modern Salesforce UX customization, and admins who master it can build sophisticated user experiences without involving developers.
How Lightning App Builder shapes the Salesforce UI
The four page types and their use cases
App Builder supports four page types. Record Pages are the detail view for an sObject (Account, Contact, custom objects). They show fields, related lists, related records, and custom components. App Pages are landing pages within a Lightning app, useful for dashboards or wizards. Home Pages are what users see when they click the Salesforce home tab. Embedded Service pages serve customers through Experience Cloud or third-party embeds. Each page type has its own canvas template and component library.
Standard components and the LDS library
Salesforce ships dozens of standard components: Highlights Panel, Record Detail, Related Lists, Tabs, Activity Timeline, Chatter Feed, Path, Quip, Topic, Files, Knowledge Component. Most record pages mix half a dozen of these with one or two custom components. The Lightning Design System (LDS) styles every standard component consistently with the Lightning Experience visual language. Custom components built with LDS classes blend in seamlessly.
Component visibility rules and personalization
Every component on a Lightning page has Component Visibility filters. Show the component when a field has a specific value, when the user has a permission set, when the device is mobile, or when a record type matches. The expression language is the same one used by Dynamic Forms. This is the mechanism that lets one record page serve multiple audiences without forking the page per profile or per record type.
Page assignment per profile, record type, and app
Each page can be assigned to a combination of app, record type, and profile. Setup > App Builder > Activation handles the assignment. The platform picks the right page for each user based on their context. Multiple active pages can coexist; the most specific match wins. Plan assignments carefully because the same record can appear differently to different users based on the active page logic.
Dynamic Forms, Dynamic Actions, Dynamic Related Lists Single
Three companion features extend App Builder''s power. Dynamic Forms places individual fields with conditional visibility. Dynamic Actions configures the record page header action buttons with conditional logic. Dynamic Related Lists Single (DRLS) lets each record page filter and sort related lists differently. Adopt all three for modernizing record pages; partial adoption leaves significant capability unused.
Performance considerations
Each component renders independently in the Lightning runtime. Pages with too many components, deeply nested tabs, or heavy custom components render slowly. Use the Lightning Page Performance Analysis tool (Setup > Performance) to measure load time. Optimization patterns: lazy-load components in collapsed tabs, limit related lists to the most-used ones, avoid running multiple Apex methods at page load. Page performance affects every record view; a slow record page degrades the entire Lightning experience.
Deploying pages between environments
Lightning pages are metadata. They deploy through change sets, metadata API, and SFDX-based pipelines like any other metadata component. Each page has a FlexiPage XML representation that can be source-controlled. Page assignments deploy alongside, but only if explicitly included in the package manifest. Forgetting to include the assignment metadata is a common deployment surprise; the page exists in production but is not assigned to any user populations.
How to build a page in Lightning App Builder
Building a Lightning page is mostly drag-and-drop, but the design choices matter: which components, in which order, with which visibility rules, deployed to which audiences. Build in sandbox, validate as multiple user personas, test performance, and deploy through your standard change pipeline.
- Identify the page need and audience
Which sObject (for record pages), which app, which profiles or record types. The audience drives the component selection and visibility rules. Sales reps need different fields and components than Support agents on the same Case record.
- Open Lightning App Builder
Setup > Lightning App Builder > New (for new pages) or Edit (for existing). Pick the page type: Record Page, App Page, Home Page, Embedded Service Page.
- Select a template and layout
Each page type offers templates: Header and Right Sidebar, Two Column, Pinned Header, etc. Pick the layout that fits the content. Templates determine the high-level structure; components fill the regions.
- Drag components onto the canvas
The component palette on the left shows standard and custom components. Drag each onto the appropriate region of the canvas. Configure component properties in the right panel. Common starting set: Highlights Panel, Record Detail (or Dynamic Forms fields), Related Lists, Activity Timeline, Chatter Feed.
- Configure component visibility rules
For each conditional component, click it, open the Component Visibility section, add filters. Show only when Stage = Closed-Won. Show only on mobile. Show only to users with the Sales Manager permission set. Build the conditional UX deliberately.
- Save and activate the page
Save the page. Click Activation. Assign to the appropriate combination of app, record type, and profile. The most specific assignment wins for each user. Confirm the assignments cover the intended audience.
- Test as multiple user personas
Log in as users from each affected profile. Verify the right components appear, the visibility rules fire correctly, and the page loads quickly. Test on different record states to confirm conditional behavior.
- Measure performance and optimize
Setup > Lightning Performance > select the page. Review load time and component breakdown. Optimize slow components, move heavy work to lazy-loaded tabs, and reduce the number of always-visible components if the page is slow.
Record Page, App Page, Home Page, or Embedded Service Page. Drives the available templates and components.
The three-dimensional combination that determines which users see this page. Most specific match wins.
Per-component conditional display based on field values, user attributes, or device type.
- Page assignments do not auto-deploy with the page metadata. Include the FlexiPage assignments explicitly in change sets or package manifests, or the page exists in production with no users seeing it.
- Too many components on one page degrades load time noticeably. Lightning Performance shows the breakdown; optimize before users complain.
- Component visibility rules evaluate client-side. The data still loads on the server; hiding a field does not prevent it from appearing in record-detail JSON responses.
- Multiple active pages can coexist with different assignments. Conflicting assignments produce confusion about which page wins; document the assignment matrix in a runbook.
- Custom components must be marked isExposed=true with the right targets in their metadata to appear in App Builder. Missing this is a common dev-side bug that surfaces at admin-side time.
Trust & references
Cross-checked against the following references.
- Lightning App Builder OverviewSalesforce Help
- Create a Lightning PageSalesforce Help
- Component Visibility RulesSalesforce Help
Straight from the source - Salesforce's reference material on Lightning App Builder.
- Lightning App Builder DocumentationSalesforce Help
- Activate a Lightning PageSalesforce Help
- Custom Components in App BuilderSalesforce Developer
Hands-on resources to go deeper on Lightning App Builder.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What architecture concept is Lightning App Builder an example of?
Q2. Who can benefit from understanding Lightning App Builder?
Q3. What does Lightning App Builder represent in the Salesforce Platform?
Discussion
Loading discussion…