--- title: "Home page design" url: "https://trailassembly.com/salesforce-home-page-design/" topic: "Admin and Permissions" published: "2026-09-21T05:07:21+00:00" updated: "2026-10-06T13:59:58+00:00" --- # Home page design **The short version:** a home page earns its place only if it answers “what should I do next” without scrolling. Build it in the Lightning App Builder, keep it to three or four components, and assign it per app and profile so a service agent and a sales manager do not get the same page. Most home pages fail not because the components are wrong but because there are nine of them and the useful one is below the fold. ## Assignment is per app, not per user When you activate a home page you get three choices, and they stack in a clear order. - **Org default.** The fallback, used where nothing more specific applies. - **App default.** Everyone in a given app gets this page. - **App and profile.** The most specific assignment, and the one that wins. So the home page is a property of the app. A user switching from the Sales app to the Service Console sees a different home page, and that is the right mental model. If two groups need different pages within one app, profile assignment is your only lever, which is another reason profiles still do real work in an org that has otherwise moved to permission sets. ## Components that earn their space The ones that consistently get used: - **A dashboard.** One dashboard, showing the numbers this audience is measured on. This is the component with the highest value and the highest page-load cost, so it should be the only heavy thing on the page. - **Today’s Tasks and Today’s Events.** Small, actionable, and the reason many users open the home page at all. - **Recent Records.** Cheap, and it saves a search dozens of times a day. - **A rich text component.** Underrated. Three links to the things this team is always hunting for, plus the current announcement, beats any amount of clever configuration. - **The Assistant,** where the app and licences support it, because it surfaces overdue work rather than making people go looking. The ones that usually do not earn it: a Chatter feed nobody posts in, a second dashboard, a report chart duplicating what the dashboard already shows, and any component added because it was available rather than because someone asked. ## Performance Every component on the home page loads when the user logs in, and the home page is the first impression of the whole system’s speed. A dashboard with a dozen charts across large objects makes login feel broken even when nothing is wrong. Keep it to one dashboard, keep that dashboard to the handful of charts that matter, and be honest about whether a chart over millions of rows belongs on a page that loads every morning at nine. If it takes seconds, link to it from the rich text component instead. ## Designing for the audience Ask each team one question: what do you look at first thing? Then build that, and nothing else. For a support team it is usually the open queue and today’s escalations. For a salesperson it is their pipeline and their overdue follow-ups. For a manager it is the team’s numbers and the exceptions. Those are three different pages, which is exactly why per-app and per-profile assignment exists. Resist the request to put everything on one page so nobody is left out. A page designed for everyone is used by nobody. The evidence is easy to gather: ask three people what is on their home page and see how many can tell you. ## The mobile caveat The Salesforce mobile app does not render the desktop home page. Mobile users get their own navigation and their own set of items, configured separately. Building a beautiful home page and assuming the field team sees it on a phone is a common and expensive assumption. ## Frequently asked **Can I set a home page for a single user?** Not directly. Assignment goes as far as app and profile. A one-person profile is possible and is usually a sign the requirement should be reconsidered. **Can home page components be conditionally visible?** Yes, component visibility rules work on the home page and can key off user fields such as role or profile, and off permissions. That lets one page serve two groups without a second page, at the cost of a page that is harder to reason about later. **Can I put a record-specific component on the home page?** No. There is no record in context, so anything that depends on one is unavailable. A list view component or a report chart is the closest equivalent. **How do I find which home page a user is getting?** Open the App Builder, click View Assignments on the page, and read the grid. If nothing matches, they are on the org default, which is often a page nobody has looked at in years. --- Source: https://trailassembly.com/salesforce-home-page-design/ Trail Assembly — independent Salesforce write-ups.