2.5 UI Settings, Home Pages, Apps, and Navigation

The UI is workflow, not security by itself

Salesforce admins configure the user experience so people can get to the right work quickly. Lightning apps, navigation items, home pages, record pages, compact layouts, actions, utility bars, themes, and UI settings all influence how the platform feels. They do not, by themselves, grant secure access to data. A user might have an object tab in navigation but no permission to read the object. Another user might have object permission but not see the tab because the app navigation does not include it.

The core Setup split is App Manager versus Object Manager. App Manager is where admins create and edit Lightning apps, choose navigation style, select navigation items, configure branding, assign user access to the app, and add utility bar items where appropriate. Object Manager is where admins configure object fields, page layouts, record types, buttons, links, actions, compact layouts, search layouts, and other object-specific behavior. Lightning App Builder sits across the experience layer by designing home pages, app pages, and record pages.

UI configuration map

Home pages are useful when they help a user start work, not when they become decorative bulletin boards. Sales users may need tasks, recent opportunities, dashboards, assistant components, or pipeline views. Service users may need case queues, today's work, knowledge access, and performance dashboards. Executives may need high-level dashboards and approvals. The admin should design from role-based workflows and then activate the page for the right app and user audience.

Lightning record pages introduce a common scenario trap. A field may be on the page layout, but a Lightning record page may use components, dynamic visibility, tabs, or related record components that affect whether the user sees it. Dynamic Forms, where available, can move fields and sections onto the Lightning page and apply visibility rules. Field-level security still applies. If a user cannot see a field, check field-level security before assuming the page is wrong.

App navigation should be intentionally narrow. A sales app should foreground leads, accounts, contacts, opportunities, tasks, dashboards, and other sales workflow items. A support app should foreground cases, contacts, accounts, knowledge, reports, queues, and service tools. Adding every object to every app creates noise and increases training cost. Removing a navigation item does not secure the object; it only removes a path. Security must still be handled through permissions and sharing.

Utility bars are powerful in console and productivity apps because they keep tools close at hand, such as notes, history, softphone, macros, or custom components. The trap is adding a utility without confirming that the target users have access to the underlying feature and that it supports their workflow. A utility bar should reduce clicks for a repeated task. It should not become a drawer of unrelated tools.

Themes and branding can help users distinguish apps and environments, but branding is not a replacement for training or access control. A production app and a sandbox may look similar unless the team intentionally labels and communicates them. Admins should avoid making environment recognition depend only on memory. In practice, clear app names, appropriate branding, login messaging where used, and release communication all help reduce mistakes.

Agentforce-related UI features should be introduced with the same discipline. If an assistant, agent action, or AI panel appears in a user workflow, the admin should understand the use case, permissions, grounding data, testing process, and monitoring expectations. Do not add AI entry points only because they are available. Add them when they serve a clear task, respect data access boundaries, and have an owner who will review outcomes.

UI troubleshooting checklist

• Can the user access the app at all through profile, permission set, or app assignment.
• Is the object included in app navigation, and does the user have object read permission.
• Is the record visible through ownership, role hierarchy, sharing, team, queue, or manual share.
• Is the field visible through field-level security and included on the relevant layout or Lightning page.
• Is the correct Lightning page activated for the app, record type, and profile combination.
• Are component visibility filters hiding content based on field values, device, or user attributes.
• Does the user have access to utility bar features, dashboards, reports, or embedded components.

A good hands-on lab is to build two Lightning apps in a practice org: Sales Workspace and Support Workspace. Give them different navigation items and home pages. Put the same object in one app but not the other, then test what changes for a user who still has object permission. Next, remove object permission and observe that navigation alone cannot create access. This exercise makes the exam distinction concrete.

The strongest admin answers balance usability and control. If users cannot find a tab, check app navigation. If users find the tab but cannot open records, check object and record access. If the record opens but the page looks wrong, check page activation, record type, profile, and component visibility. If users ask for a custom app, ask which jobs the app should make faster before copying an existing app and adding more tabs.