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.