Collapsible Section
A Collapsible Section is a Lightning record page or page layout container that users can expand and collapse to show or hide its child fields and components.
Definition
A Collapsible Section is a Lightning record page or page layout container that users can expand and collapse to show or hide its child fields and components. The admin marks a section as collapsible at design time; users see a chevron icon on the section header that toggles visibility. Collapsed sections persist per user (the page remembers which sections each user keeps collapsed), so reps configure their own visual default once and the page respects it across visits.
Collapsible Sections exist to manage information density on record pages with many fields. A standard Account page can hold dozens of fields across multiple sections (Account Information, Address Information, Account Details, System Information, Custom Fields). Without collapsible sections, every record load shows everything; with them, users collapse the sections they rarely need and focus on the data that drives their daily work. The default-collapsed setting is the admin's hypothesis about what most users want; users override per their preference and the page adapts.
Why collapsible sections are the cheapest way to make dense pages usable
Where Collapsible Sections live in page configuration
Lightning Record Pages built in App Builder support Collapsible Sections through the Accordion component or through section properties on the Details tab. Classic Page Layouts support a similar pattern through the Section Properties dialog (right-click a section, toggle Collapsible). Both paths produce the same user experience: a chevron icon on the section header, collapsed state persisted per user. App Builder is the modern approach and supports more flexibility (per-section default-collapsed state, conditional visibility, component-level collapse).
Default state and the admin hypothesis
Each Collapsible Section has a default state (expanded or collapsed). The default applies to users who have not personally adjusted that section. Setting a section to default-collapsed is the admin's hypothesis that most users would not want to see it on every page load (System Information for non-admin users is a common candidate). Users can override per-section; the override persists. Setting too many sections to default-collapsed hides information users do need; the right balance depends on the user role and the object's typical workflow.
Per-user persistence and the cross-device experience
Collapsed state persists per user per section per object. A user who collapses the Address Information section on Account sees that section collapsed across every Account record. The persistence is user-scoped, so two users on the same record can have different sections collapsed. The persistence is also device-aware in newer Lightning versions; collapse state syncs across browsers and devices for the same user. The user controls their own view; the admin controls the defaults.
Conditional visibility and the better alternative
For information that should appear only under specific conditions (a Renewal section that only matters when Account Type equals Customer-Renewal), conditional visibility is usually better than collapsible. Conditional visibility hides the section entirely when conditions are not met; users do not see a collapsed section they would never expand. Collapsible is right when the section is sometimes relevant; conditional is right when it is sometimes irrelevant. Use both together for the cleanest experience.
Accordion vs Tabs vs Collapsible Sections
Three Lightning patterns manage information density. Accordion is a vertical stack where one section is expanded at a time. Tabs are horizontal labels where one tab shows at a time. Collapsible Sections are independent toggles where any subset can be open simultaneously. Each has its use case. Accordion fits sequential workflows where the user moves through sections in order. Tabs fit clearly separated topic areas. Collapsible fits the "user picks what to see" pattern. Most rich record pages mix all three: tabs at the top level, accordion or collapsible sections within each tab.
Performance and the rendering cost question
Collapsed sections in modern Lightning still render their content in the DOM; the collapse just hides it visually. Performance-sensitive pages with heavy related lists or large rich text fields may want conditional visibility instead so the content does not render at all. The difference matters most on pages with 10+ sections, several large related lists, or embedded LWC components that fetch data on render. For typical pages with field-only sections, the performance impact of collapsible is negligible.
Mobile and the collapsed-by-default pattern
The Salesforce Mobile App renders Lightning record pages with the same Collapsible Sections. On the smaller screen, default-collapsed is more often the right choice; sections that hide on mobile show on desktop and vice versa is possible but adds complexity. Most teams use the same default across mobile and desktop, accepting that the mobile experience may be slightly busier. The mobile-first version is to default more sections to collapsed and rely on user expansion when needed.
How to use Collapsible Sections to make dense pages usable
The pattern: identify low-frequency sections, set them default-collapsed, leave high-frequency sections default-expanded, watch usage. The cost is minimal; the readability gain is meaningful for any page with more than 5 to 7 sections.
- List the sections on the page
Open the Lightning Record Page in App Builder. Count the sections. Pages with fewer than 5 sections probably do not need collapsible defaults; pages with 8+ sections benefit a lot.
- Identify the high-frequency sections users always need
The top one or two sections (Account Information, Opportunity Details) usually stay default-expanded. Everything else is candidate for default-collapsed.
- Mark low-frequency sections as default-collapsed
Click into each section, toggle Default Collapsed. System Information, Audit Fields, archival sections are typical candidates.
- Pair with conditional visibility where applicable
Sections that should only appear under specific conditions get conditional visibility instead of (or in addition to) collapsible. Cleaner than collapsing always-irrelevant sections.
- Test on mobile viewport
Open the page on a phone-sized window or actual mobile device. Confirm the default-collapsed state matches what mobile users want to see first.
- Publish and gather feedback
Activate the page. Watch for user complaints about hidden information; the defaults are the admin's hypothesis and users will tell you if you got it wrong.
- Refine quarterly based on usage signals
Lightning Usage Reports show which components users interact with most. Sections users always expand should become default-expanded; sections users never expand should be considered for conditional visibility or removal.
Per-section setting; the admin's hypothesis about what most users want to see on load.
Show or hide entire sections based on field values. Better than collapsible for always-or-never information.
Three information-density patterns. Pick based on the user workflow.
Mobile users see the same collapsible defaults unless a separate mobile page is built. Most teams use one shared layout.
Collapse state persists per user per section. Users control their own view across visits.
- Over-using default-collapsed hides information users need on every visit. Reps complain about repeated expansion clicks; recalibrate based on real usage.
- Collapsed sections still render in the DOM. Performance-sensitive pages should use conditional visibility for heavy components, not just collapse.
- Default state applies only to users who have not personally adjusted. Tenured users keep their settings; admin defaults shift only for new or unchanged users.
- Mobile and desktop share the same collapsible defaults unless separate mobile pages are built. A default that works on desktop may feel busy on mobile.
- Collapsible is sometimes used as a substitute for proper page design. Pages with too many sections need restructuring, not just collapsing.
Trust & references
Cross-checked against the following references.
- Collapsible Sections referenceSalesforce
- Lightning App Builder overviewSalesforce
Straight from the source - Salesforce's reference material on Collapsible Section.
- Collapsible SectionsSalesforce Help
- Lightning App BuilderSalesforce Help
- Dynamic Forms (Conditional Visibility)Salesforce Help
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 does a Collapsible Section let users do?
Q2. Where are collapsible sections configured?
Q3. When are collapsible sections most useful?
Discussion
Loading discussion…