Customizing the Salesforce User Interface is a four-piece configuration discipline: design the page layouts and component arrangements through Lightning App Builder, manage the navigation through App Manager, build custom UI through Lightning Web Components when standard components do not fit, and enforce consistency through permission sets and profile-specific UIs. Each piece serves a different need; mature orgs use all four together. Skipping the documentation step is the most common reason multi-admin orgs accumulate inconsistent UI experiences over time.
- Design page layouts in Lightning App Builder
For each record page in Lightning Experience, open Lightning App Builder and arrange the components: highlights panel at the top, tabs for related lists and activities in the middle, custom components on the right rail. Drag standard Salesforce components (Related List, Activity Timeline, Chatter) into place; add custom Lightning Web Components for org-specific functionality. Assign the page to a specific app, profile, or record type combination so different audiences see different layouts. Test as each target user before activating the page. Document the page-layout-to-audience mapping in the org UI runbook for audit.
- Manage navigation through App Manager
From Setup, open App Manager. Build Lightning Apps for each user audience (Sales Console, Service Console, Marketing Hub, etc.). Each app has a navigation bar with specific tabs (objects, custom pages, dashboards) ordered for that audience. Assign apps to user profiles or permission sets. Lightning Bolt or Lightning Experience Configuration Converter can speed up the build for orgs migrating from Classic. Test the navigation in each app before deploying. Set the default app per profile so users land in the right experience on login.
- Build custom UI through Lightning Web Components
For UI requirements that standard components do not handle, build a Lightning Web Component. Use Salesforce DX in VS Code to scaffold the component (sf project generate). Build the HTML template, the JavaScript controller, and the CSS stylesheet. Deploy the component to the org through the Salesforce CLI. Add it to the component metadata so Lightning App Builder can drop it onto record pages. Run unit tests with Jest. Run user acceptance testing in sandbox before production deployment. Document the component purpose, props, and usage in the project README.
- Enforce UI consistency through documentation and review
Document the org UI conventions in a Confluence page or in the project README: which page layouts exist for which audiences, which custom components are approved for use, which page-builder patterns are forbidden (multi-tab record pages, infinite-scroll related lists). Run quarterly UI reviews where new admin-built pages are reviewed against the conventions. Use Salesforce Optimizer to flag unused page layouts and orphaned Lightning pages. Without active governance, the org UI accumulates inconsistencies that confuse users and degrade the platform perceived quality over time.
- Salesforce Classic and Lightning Experience use different metadata for page layouts. A Classic Page Layout does not apply to Lightning record pages; you need a separate Lightning Page in App Builder for each layout per audience.
- Lightning App Builder pages can be assigned per profile, per record type, and per app. The assignment hierarchy is order-dependent; an admin who assigns the same page in two places without understanding the precedence creates surprising behavior.
- Custom Lightning Web Components require deployment through metadata. Building them in Developer Console works for prototypes but does not scale; use Salesforce DX in VS Code with a Git repo for production work.
- Visualforce pages and Aura Components still work in Lightning Experience, but they often feel different from native Lightning components. Plan migration of high-traffic Visualforce pages to LWC during Lightning modernization.
- Salesforce Mobile App rendering is a subset of Lightning Experience. Some components do not render correctly on mobile; test every custom component on a real device before declaring it production-ready.