Detail View
Detail View is the full record-view page in Salesforce: the page that shows a single record's fields, related lists, activity timeline, and Chatter feed.
Definition
Detail View is the full record-view page in Salesforce: the page that shows a single record's fields, related lists, activity timeline, and Chatter feed. It is the primary interface users hit when they click into a specific Account, Opportunity, Case, or any other record. The Detail View is composed of several Lightning components (Highlights Panel at the top, Detail section in the middle, Related Lists and Activity timeline alongside or below) and is configured through Lightning App Builder for Lightning Experience or page layouts for Salesforce Classic.
The Detail View is distinct from a List View (the table of multiple records) and from the Edit View (the inline or full-page edit experience). In Lightning, the URL pattern /lightning/r/ObjectApiName/RecordId/view consistently identifies a Detail View, while /edit opens the edit experience for the same record. Configuration choices made in the Detail View affect what every user sees when they open a record, gated by per-profile or per-record-type assignment.
What makes up a Salesforce Detail View
The anatomy of a Lightning Detail View
A Lightning Detail View has several stacked or side-by-side components: the Highlights Panel (top strip with key fields and primary actions), the Path component (sales stage or case status progress), the Detail Section (fields driven by a page layout or Dynamic Forms), Related Lists (child records like Opportunities under an Account), the Activity timeline (tasks, events, calls), and the Chatter feed. Each component is configurable independently in Lightning App Builder; admins can show, hide, and reorder them per profile or record type.
Classic versus Lightning Detail Views
Salesforce Classic Detail Views are driven entirely by page layouts: one layout per profile or record type defines the order of fields, related lists, and buttons. Lightning Detail Views can use the same page layouts (the Detail Section component points to one) or can use Dynamic Forms for per-field placement and visibility. The Classic-to-Lightning migration is largely about reorganizing what was one page layout into multiple Lightning components.
Activation, assignment, and right-page-for-the-right-user logic
A Lightning Record Page can be assigned at three levels: as the org default for the object, as a profile-specific default, and as an App-and-Record-Type-specific assignment. The platform picks the most specific match at runtime. This is how a single object (Case, for instance) can present different Detail Views to support agents, sales managers, and partners on a community.
Dynamic Forms and per-field visibility
Before Dynamic Forms, hiding a field on a Detail View required creating a separate page layout per profile that needed the field hidden. Dynamic Forms (Spring '23 for all standard objects, earlier for custom objects) lets you place individual Field components with visibility rules: show this field only when a record's Type is Premium, or hide it for read-only users. The result is one Lightning Record Page that adapts to the record and the user.
Related Lists on the Detail View
Related Lists are how a Detail View shows child records: Contacts under an Account, Opportunities under an Account, Cases for a contact. Each related list is a configurable component on the Lightning Record Page: pick which fields to show, how many records to display, the sort order, and which actions are available. The list of available related lists comes from the object's relationships in the data model.
Console apps and the workspace-tab Detail View
Service Cloud and Sales Cloud Console apps render Detail Views inside workspace tabs. The same Lightning Record Page powers a console tab and a standard navigation Detail View, but the console adds tab management, sub-tabs for related records, and a utility bar. Console apps are where Detail Views show their full UI value: agents can have a Case Detail View open with three Contact Detail Views as sub-tabs and still see the macros utility bar at the bottom.
Performance: components, queries, and render time
A Detail View with 30 components, three Lightning components from managed packages, and 12 related lists takes longer to render than a streamlined one. The Lightning Page Performance Profiler (Setup, then Performance Analyzer) shows component-level timing for any Detail View. The biggest wins usually come from removing unused related lists, reducing Apex-backed Lightning components, and consolidating page layouts via Dynamic Forms.
How to customize a Detail View in Lightning App Builder
Customizing a Detail View means editing the Lightning Record Page in Lightning App Builder. The page composes components for a specific object's record view; activation rules decide which users see which page.
- Open Lightning App Builder
Setup, then Lightning App Builder. Find the existing Lightning Record Page for the object, or click New to create one. Pick Record Page as the type.
- Review the canvas
The canvas shows the components currently on the Detail View. Highlights Panel at the top, the Detail Section or Dynamic Forms components in the body, Related Lists and Activity timeline in the right or bottom regions.
- Add, remove, or reorder components
Drag Lightning components from the left palette: standard (Detail Section, Related Lists, Path, Activity, Chatter) and custom (LWC or Aura). Reorder by dragging within the canvas. Each component has its own properties on the right rail.
- Configure component properties
Click a component to see its properties. For the Detail Section, pick the page layout or switch to Dynamic Forms. For Related Lists, choose which lists to show. For custom components, set the API attributes.
- Set component visibility rules
Each component supports filters: show only when a record matches certain criteria, or only for users in certain profiles. Use this to surface special components on premium accounts or hide internal-only sections from community users.
- Save and activate
Click Save. Click Activation. Set the page as the org default, a profile default, or an app-and-record-type assignment. The new Detail View takes effect immediately for matching users.
The Lightning Record Page editor. Drag components, set properties, configure activation rules.
Replace the single Detail Section with field-by-field placement. Per-field visibility rules and column control.
The legacy way to drive a Detail View. Still works in Lightning when the Detail Section component points to a layout.
Drives the fields shown in the top strip of the Detail View. Set per object in Object Manager.
- Activation order matters: app-and-record-type, then profile, then org default. The most specific match wins, so a profile-specific assignment overrides the org default for that profile.
- Dynamic Forms and the Detail Section component are mutually exclusive on a single page. You either drive fields through a page layout or place them as individual Field components, not both.
- Custom Lightning components on a Detail View can slow page render. Profile with the Lightning Page Performance Profiler before adding more than five custom components.
- Removing a Related List from the Detail View hides it but does not delete the relationship or the records. The child records remain reachable through other Detail Views or list views.
Trust & references
Straight from the source - Salesforce's reference material on Detail View.
- Lightning App Builder OverviewSalesforce Help
- Assign Lightning Record PagesSalesforce Help
- About Dynamic FormsSalesforce 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 is the Detail View?
Q2. How is the Detail View customized in Lightning?
Q3. Why does Detail View design matter so much?
Discussion
Loading discussion…