Hover Detail
Hover Detail is the Salesforce feature that shows a small popup preview of a record when a user points their cursor at the record's name or a lookup link, without opening the full record.
Definition
Hover Detail is the Salesforce feature that shows a small popup preview of a record when a user points their cursor at the record's name or a lookup link, without opening the full record. In Salesforce Classic, where the name originates, this preview is configured through the Mini Page Layout and is switched on by the org-level Enable Hover Details setting. The popup lets someone scan a list view, a related list, or the Recent Items sidebar and read a few key fields at a glance.
The Classic Hover Detail (driven by the Mini Page Layout) is the older, separately configured version of this idea. Lightning Experience kept the hover preview but changed how it is built. In Lightning the same popup is driven by the Compact Layout, the configuration that also feeds the Highlights Panel, the mobile app, and search results. If you are building new today, you customize the Compact Layout, not a Mini Page Layout. The Classic Hover Detail still works for orgs on Classic, but it is legacy.
From Mini Page Layouts to Compact Layouts
What the Classic hover popup actually was
In Salesforce Classic, Hover Detail meant a popup that appeared when a user moused over a record link. It surfaced in list views, in related lists on a detail page, and over lookup links in the Recent Items area of the sidebar. The point was speed. A rep scanning a long list of contacts could read an email, a phone number, and the related account without clicking into each record one by one. The popup was not free-form. It read from a per-object configuration called the Mini Page Layout, which lived inside each page layout. An admin opened a page layout in the original editor, clicked Mini Page Layout in the header, and chose which fields and which related lists appeared in the hover. The whole feature was gated by a single org-level switch, Enable Hover Details, found under Setup, Customize, User Interface. Turn that off and no hover popups appeared anywhere in Classic. This two-part design, a global toggle plus a per-layout Mini Page Layout, is what makes the Classic version distinct from the modern one.
How Lightning Experience rebuilt the same idea
Lightning Experience kept the hover preview but rebuilt the plumbing. Instead of a Mini Page Layout, the Lightning hover reads from the object's Compact Layout. The same Compact Layout drives the record Highlights Panel at the top of a page, the record view in the Salesforce mobile app, and how records appear in search results. So one configuration now feeds several surfaces at once. According to Salesforce documentation, Compact Layouts control the fields shown in the expanded lookup card you see when hovering over a link in record details, and they also feed the activity timeline preview. The Highlights Panel shows up to the first seven fields of the Compact Layout, with the first field rendered as an accented title. Because the hover and the Highlights Panel share the same source, you cannot tune one without affecting the other. That is the trade for the simpler model. There is no separate Hover Detail editor in Lightning; the Compact Layout is the single place you edit.
Case hovers, a special Lightning surface
Cases get their own documented hover behavior in Lightning Experience. When an agent hovers over a case link, the popup is split into three sections: the title and top fields, the description, and the latest update. You control the first section by editing the Case Compact Layout. The hover shows only the first five fields, and the first field becomes the title, so Salesforce recommends putting Subject first. The description and latest update sections are not customizable. They are populated automatically from the case record. This matters for service teams. An agent triaging a queue can hover a case and read the subject, a couple of status fields, the description, and the most recent comment, all without opening the record. To set it up you go to Setup, Object Manager, Case, Compact Layouts, then either edit the default layout or create a new one and assign it as the primary Compact Layout. The field order you set is the order shown in the hover, top to bottom.
Field-level security still applies
A hover popup is not a way around security. Whether the preview comes from a Classic Mini Page Layout or a Lightning Compact Layout, it respects field-level security. If a user lacks read access to a field, that field is simply absent from the popup for that user. There is no placeholder and no padlock; the row just is not there. This creates a design problem that catches admins. You build a Compact Layout with five useful fields, the hover looks great for you as a System Administrator, and then a rep on a tighter profile sees a hover with two fields because the other three are hidden by FLS. The fix is to design the layout against your most restricted relevant profile, not against your own full access. Test the hover while logged in as, or impersonating, a user on that profile. A sparse or blank hover popup reads worse to users than no popup at all, because it looks broken rather than intentional.
Touch devices do not hover
Hover is a mouse gesture. Phones and tablets do not have one, so the hover preview behaves differently or disappears on touch. The Salesforce mobile app does not show a desktop-style hover popup; tapping a record link navigates to the record. On a tablet running the Lightning desktop UI, the browser may fall back to a tap, which can trigger an unintended navigation instead of a preview. This has a practical consequence for workflow design. If you support a service or field team that works primarily on tablets, do not design a process that assumes users can hover to read details. Build the flow so the needed information is on the screen they land on, or accept that they will tap into each record. Treat the hover preview as a desktop-with-mouse convenience, not as a guaranteed part of the interface. The same caution applies to accessibility, since keyboard-only and screen-reader users may not trigger a hover the way a mouse user does.
What to do if you are still on Classic
Plenty of orgs still run Salesforce Classic, and there the Classic Hover Detail and its Mini Page Layouts are perfectly valid. If you are maintaining a Classic org, you keep the Enable Hover Details setting on and curate each object's Mini Page Layout the way you always have. Nothing is broken. The thing to know is the migration path. When an org moves to Lightning Experience, hover content stops coming from the Mini Page Layout and starts coming from the Compact Layout. The two are configured separately and can drift apart, so a record that showed five fields on hover in Classic might show different fields, or fields in a different order, in Lightning. The migration is largely automatic, but the Mini Page Layout settings do not copy themselves into the Compact Layout. Before you flip Lightning on for high-traffic objects like Account, Contact, and Case, review each Compact Layout and confirm the hover preview shows what your users expect. Treat the Mini Page Layout as documentation of intent, then rebuild that intent in the Compact Layout.
A worked example: a contact hover
Say your sales team lives in a Contacts list view and wants to qualify rows quickly. In a Lightning org you open Setup, Object Manager, Contact, Compact Layouts, and edit the primary Compact Layout. You add Name, Title, Account Name, Email, and Phone, in that order. Now hovering a contact in the list view shows a popup with the name as the title and the other four fields below it, and the same five fields appear in the Highlights Panel on the contact record and in the mobile app. If a junior rep on a restricted profile cannot see Phone, that rep's hover shows four fields, not five, and nothing signals why. So you check the profile, confirm Phone is the only gap, and decide whether to grant read access or drop the field. In a Classic org the same result comes from the Contact page layout's Mini Page Layout instead, and you would also confirm Enable Hover Details is on. Same goal, two different configuration homes, depending on which UI the org runs.
Configuring the hover preview in Classic and Lightning
The hover preview is not edited in one place anymore. In Lightning Experience you shape it through the object's Compact Layout; in Salesforce Classic you shape it through the page layout's Mini Page Layout and the org-level Enable Hover Details switch. These steps cover both so you can configure whichever UI your org runs.
- Decide which UI you are configuring
If your org runs Lightning Experience, you will edit a Compact Layout. If it runs Classic, you will edit a Mini Page Layout and confirm the Enable Hover Details setting. The hover content does not come from the same place in both, so identify the UI first.
- Lightning: edit the Compact Layout
Go to Setup, Object Manager, pick the object (for example Contact or Case), and click Compact Layouts. Edit the primary Compact Layout or create one and assign it as primary. Add the fields you want and order them; the first field becomes the hover title.
- Classic: enable hover details and set the Mini Page Layout
In Classic, confirm Setup, Customize, User Interface, Enable Hover Details is checked. Then open the object's page layout, click Mini Page Layout in the header, and choose the fields and related lists that should appear in the hover popup.
- Test as a restricted user
Field-level security removes hidden fields from the popup. Log in as, or impersonate, a user on your most restricted relevant profile and hover a record. Confirm the preview shows the fields you intended and is not sparse or blank for that profile.
The single source for the Lightning hover, the Highlights Panel, the mobile record view, and search results. Editing it changes all of those at once.
The per-page-layout configuration that defines Classic hover content. Found inside each page layout, separate from the Lightning Compact Layout.
The org-level switch under Setup, Customize, User Interface that turns Classic hover popups on or off everywhere.
Controls the title and top five fields of the Case hover in Lightning; the description and latest update sections are filled automatically and cannot be customized.
- The Lightning hover and the Highlights Panel read the same Compact Layout, so you cannot change one without changing the other.
- Mini Page Layout settings do not copy into the Compact Layout when an org moves to Lightning; rebuild the intent rather than expecting it to migrate.
- A field hidden by field-level security disappears from the hover with no placeholder, which can make a popup look broken for restricted profiles.
- Touch devices do not hover, so tablet and mobile users tap into the record instead of seeing a preview; do not design workflows that depend on hovering.
Prefer this walkthrough as its own page? How to Hover Detail in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Hover Detail.
Hands-on resources to go deeper on Hover Detail.
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. In Lightning Experience, which configuration drives the fields shown in a Hover Detail popup?
Q2. What did Salesforce Classic use to power its hover previews before Lightning unified the configuration?
Q3. A user with no read access to a field configured in the Compact Layout hovers over a record. What happens to that field in the Hover Detail popup?
Discussion
Loading discussion…