Mini Page Layout
A Mini Page Layout is a Salesforce Classic configuration that controls the small subset of fields and related lists shown in compact surfaces like hover details, calendar event overlays, and the Agent Console mini view.
Definition
A Mini Page Layout is a Salesforce Classic configuration that controls the small subset of fields and related lists shown in compact surfaces like hover details, calendar event overlays, and the Agent Console mini view. It is a trimmed view of an object's full Page Layout. A mini layout inherits record type associations, profile associations, related lists, fields, and field access settings from its parent Page Layout, then lets an admin pick which of those fields and lists actually appear in the condensed display.
Mini Page Layouts are an older, Classic-only concept. Lightning Experience does not use them. The Compact Layout took over the same job in Lightning, driving the Highlights Panel at the top of a record, the hover lookup card, the activity timeline, search previews, and the Salesforce mobile app from one definition. Orgs on Lightning configure Compact Layouts instead, so a Mini Page Layout in a Lightning org is effectively dead metadata.
How Mini Page Layouts shaped the Classic experience
What the mini layout actually controlled
A Mini Page Layout governed three Classic surfaces at once. The first is hover detail, the popup that appeared when a user moused over a record name in a list view, a related list, or a lookup field. The second is the event overlay on the Classic calendar, the small card shown when you hover over a meeting. The third is the mini view inside the Agent Console, the narrow panel that summarized a related record while the agent worked a primary case. All three drew their fields from the same mini layout, so one configuration kept those previews consistent. The point was speed. A rep scanning a list could see the key facts about a record without clicking into it and losing their place. Because the mini layout was a subset of the full Page Layout, it never introduced new fields of its own. It only narrowed down what the parent layout already exposed, which kept field-level security and read-only behavior intact across every preview.
Inheritance from the parent Page Layout
The mini layout did not stand alone. It inherited record type associations, profile associations, related lists, fields, and field access settings straight from the Page Layout it belonged to. That inheritance had practical consequences. Field properties such as read-only status came from the parent, so an admin could not loosen security in the mini view. Fields flagged as Always Displayed on the full layout were forced into the mini layout and could not be removed. The mini layout also capped related lists at five, a deliberate limit to keep the condensed panel readable. Selected fields and related lists showed even when they held no data, so an empty field still occupied a row. This design meant the mini layout was genuinely a filter on top of the page layout, not a separate object. Change the parent layout's field access and the mini view reflected it. That tight coupling reduced drift between the full record page and its previews, which mattered when many record types shared one base layout.
Editing a Mini Page Layout in Setup
Admins reached the mini layout through the page layout editor, not a separate menu. From an object's Page Layouts list you clicked Edit next to a layout, then clicked the Mini Page Layout link in the layout header. That opened a focused editor showing the fields and related lists the parent layout exposed. You used Add and Remove to choose which fields appeared, and the up and down arrows to set their order. Related lists worked the same way, with the five-list ceiling enforced. The standing advice was to keep the selection short. A mini layout crammed with fields forced users to scroll inside a popup, which defeated the purpose of a quick glance. Because the mini layout was bound to a specific page layout, an org with several page layouts (often one per record type) carried several mini layouts too. Each one could surface different fields, so a New Business opportunity preview and a Renewal opportunity preview could highlight different information. The platform chose the right mini layout based on the viewer's profile and the record's type.
Per record type and per profile behavior
Mini Page Layouts followed the same assignment model as the page layouts they came from. Salesforce decides which page layout a user sees based on their profile and the record's record type, and the mini layout rode along with that decision. If a profile saw the Renewal page layout for the Renewal record type, that profile also saw the Renewal mini layout in hover detail and the console mini view. Admins did not assign mini layouts directly. They assigned page layouts in the layout assignment matrix, and the mini layout assignment was implied. This kept the model simple but also meant you could not give one mini view to one profile and a different mini view to another profile unless they were already on different page layouts. For most orgs that constraint was fine, since record type and profile usually lined up with distinct page layouts anyway. The result was a preview experience that matched each user's normal record page, just compressed into a handful of the most useful fields.
The Compact Layout took over in Lightning
Lightning Experience retired the mini layout and handed its responsibilities to the Compact Layout. A Compact Layout is configured under Setup, Object Manager, then Compact Layouts, completely separate from the page layout editor. It drives more surfaces than the old mini layout ever did. Up to the first seven fields in a Compact Layout appear in the Highlights Panel at the top of a record. When a user hovers over a lookup field, the first five fields from that object's Compact Layout fill the expanded lookup card. The same definition also feeds the activity timeline's expanded view, search result previews, and the Salesforce mobile app, all from one place. The Highlights Panel is in fact the one part of a Lightning record page you cannot edit with the page layout editor, since it relies entirely on the Compact Layout. That single source of truth is the big shift. Where Classic split previews across page-layout-bound mini layouts, Lightning centralizes them in a dedicated Compact Layout per object.
Migrating off mini layouts and exam relevance
When an org moves from Classic to Lightning, its Mini Page Layouts stop doing anything. The Compact Layout replaces them, and the field selection usually needs a rethink rather than a copy. A mini layout only fed the hover popup, but a Compact Layout feeds the Highlights Panel, the hover card, mobile, and search at once. A field that reads well in a desktop popup may crowd a phone screen or a tight highlights bar, so the right move is to design the Compact Layout for those broader surfaces from scratch. Salesforce documents this directly for cases: to change the title and fields in a Lightning case hover, you edit the case Compact Layout rather than any mini layout. On the certification side, older Administrator and Sales Cloud Consultant material referenced mini layouts, but current exams test Compact Layouts. For any modern question, knowing that the Compact Layout is the Lightning successor to the Mini Page Layout is enough to answer correctly.
Configure a Mini Page Layout in Salesforce Classic
Mini Page Layouts only apply in Salesforce Classic. If your org runs Lightning Experience, skip this and configure a Compact Layout instead. These steps show how an admin trims a mini layout from the original page layout editor in Classic.
- Open the object's page layout
In Setup, go to the object's Page Layouts list. Click Edit next to the page layout whose mini view you want to adjust. The mini layout is bound to this specific page layout.
- Click the Mini Page Layout link
In the page layout header, click Mini Page Layout. This opens an editor showing the fields and related lists the parent layout already exposes. You are filtering that set, not adding new fields.
- Select fields and related lists
Use Add and Remove to choose which fields appear in hover detail and the console mini view. Reorder with the up and down arrows. You can include up to five related lists. Keep the list short to avoid scrolling.
- Save and verify
Click Save. Hover over a record of this layout's record type in a list view to confirm the popup shows the fields you picked. Always Displayed fields from the parent layout appear automatically.
The subset of the parent layout's fields shown in the mini view. Field access and read-only status are inherited and cannot be changed here.
Up to five related lists from the parent layout. They display in the console mini view even when they contain no records.
Fields marked Always Displayed on the full page layout are forced into the mini layout and cannot be removed.
- Mini Page Layouts do nothing in Lightning Experience. Configuring one in a Lightning org is wasted effort; use the Compact Layout.
- You cannot add a field that is not already on the parent page layout. The mini layout is strictly a subset.
- You cannot assign a mini layout independently. It follows whichever profile and record type assignment the parent page layout has.
- A long mini layout forces users to scroll inside the hover popup, which undercuts the quick-glance purpose.
Prefer this walkthrough as its own page? How to Mini Page Layout in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Define Mini Page Layouts for the Agent ConsoleSalesforce
- Compact LayoutsSalesforce
Straight from the source - Salesforce's reference material on Mini Page Layout.
Hands-on resources to go deeper on Mini Page Layout.
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. What did a Mini Page Layout control in Salesforce Classic?
Q2. Where did an admin configure a Mini Page Layout in Salesforce Classic?
Q3. What replaced the Mini Page Layout when orgs moved to Lightning Experience?
Discussion
Loading discussion…