Record Page Settings
Record Page Settings is a Setup page in Salesforce that controls the default view used for Lightning Experience record pages across an org.
Definition
Record Page Settings is a Setup page in Salesforce that controls the default view used for Lightning Experience record pages across an org. From this single screen, an administrator decides whether records open in Grouped View, the standard tabbed and sectioned layout, or in Full View, a single scrollable column that places details near the top and related lists below.
The page does not build record layouts itself. Lightning App Builder still composes each page and handles activation by org default, app, profile, and record type. Record Page Settings sits one level above that work and sets the reading experience users get when they land on a record.
What Record Page Settings actually controls
Grouped View versus Full View
The setting offers two reading modes for record pages. Grouped View is the default Lightning Experience experience, where fields sit in a details tab and related lists live in their own tab or region, often inside collapsible sections. It keeps the screen compact and pushes secondary information behind tabs. Full View takes the opposite approach. It drops everything onto one long scrollable column, with field details near the top and every related list stacked underneath. The effect feels closer to Salesforce Classic, which is why teams moving off Classic sometimes prefer it. Neither mode changes which fields or related lists appear. That still comes from the Lightning page and page layout assigned to the object. The choice only changes how that same content is arranged and how much scrolling versus tab-clicking a user does. Some users like seeing all related lists at once without hunting through tabs. Others find the long column slower to scan. Because the trade-off is about reading habits, the right answer depends on how your users work, not on a single best practice.
Where it lives and how you set it
You reach the page by typing Record Page Settings into the Quick Find box in Setup. The control sets the org default view, so by default it applies to records everywhere unless a narrower assignment overrides it. When you switch the default to Full View, Salesforce shows a list of the Lightning pages that are currently set as org defaults, split by Desktop and Phone form factor. You then pick which of those org-default pages should render in Full View. This is an important detail. Full View only applies to pages that already hold the org default assignment for an object. A custom Lightning page assigned to a specific app, profile, and record type combination does not get Full View from this screen. The setting is also activatable in narrower ways through page activation, so you can offer Full View to one app or one profile while leaving the rest on Grouped View. Treat the screen as a switch for the default reading mode, then handle anything more targeted during page assignment in Lightning App Builder.
How it differs from Lightning App Builder
People often confuse this page with the work they do inside Lightning App Builder, and the two really are separate jobs. Lightning App Builder is where you drag components onto the canvas, build field sections, add related list components, and decide which Lightning page a given app, profile, and record type sees. That tool answers the question of what appears on the page and who sees which version. Record Page Settings answers a different question. It decides the default reading mode, Grouped or Full, for the pages already in place. Think of App Builder as composing the content and Record Page Settings as choosing the frame around it. A page you built with Dynamic Forms, a Highlights Panel, and several related lists can render in either mode. The mode does not undo or change that composition. Keeping the distinction clear helps when you troubleshoot. If a user reports a missing field, that is an App Builder or page layout question. If they report that everything is on one scrolling page instead of tabs, that is the view mode set here.
Availability limits and performance
Full View is not guaranteed for every org. Salesforce gates it to protect performance, because rendering every related list at once on a single page can be heavier than loading them lazily behind tabs. Records with many related lists, large numbers of fields, or unusually complex page composition are the ones most likely to feel the difference. For that reason the platform does not expose Full View in all org configurations, and you may find the option unavailable or restricted depending on your setup. When Full View is available, test it against your busiest objects first. Open a record that has a long stack of related lists and watch how it loads on both desktop and phone form factors. The single-column layout that feels convenient on a light record can feel sluggish on a heavy one. This is also why the setting ties to specific org-default pages rather than flipping the whole org blindly. You get to opt individual pages in, observe the result, and back out a page if its load time suffers. Measure on real records, not on a thin sandbox example.
A short history of the feature
Full View arrived as a Beta in the Spring 20 release, then reached General Availability in Summer 20. Before it existed, Lightning Experience offered only the grouped, tabbed arrangement, and admins migrating from Classic frequently heard that users missed seeing everything on one page. Full View was the answer to that feedback. The General Availability version carried the same behavior as the Beta and opened the option to qualifying orgs, with the performance gating described above. Knowing the timeline matters for two reasons. First, older training material and screenshots may not mention Full View at all, so a team that adopted Lightning years ago might not realize the option exists. Second, the Grouped versus Full choice is genuinely a preference rather than a deprecation. Grouped View was not retired when Full View shipped, and both remain valid today. So this is not a case of moving off an old pattern onto a new one. It is one Setup switch that lets you match the record reading experience to how a given team actually likes to consume information on a record.
When to choose each mode
Reach for Full View when your users came from Salesforce Classic and keep asking to see details and related lists together without clicking through tabs. Sales and service teams that scan a record top to bottom during a call often like having everything in one column. Reach for Grouped View when records carry a heavy load of fields and related lists, when phone users matter, or when a tabbed layout keeps people focused on one block of information at a time. Grouped View also pairs naturally with Dynamic Forms, where field sections already give you fine control over what shows and when. There is no rule that the whole org must match. Because you can activate Full View for specific apps or profiles, a common pattern is to give one team the single-column reading mode while everyone else stays grouped. Decide based on observed behavior. Watch how a few representative users move through a record, ask which arrangement saves them clicks, and pick the mode that fits. Then document the decision so the next admin understands why a given object reads the way it does.
How to switch records to Full View
Use Record Page Settings to switch the org default record view to Full View, then opt in the specific org-default Lightning pages that should use it. Do this in a sandbox first and test against records that carry many related lists.
- Open Record Page Settings
In Setup, type Record Page Settings into the Quick Find box and select the page. Confirm you are working in a sandbox or test org before changing the org default.
- Choose Full View as the default
Change the default record page view from Grouped View to Full View. Salesforce then lists the Lightning pages currently set as org defaults, grouped by Desktop and Phone form factors.
- Select which pages use Full View
Pick the org-default pages that should render in Full View. Pages assigned only to a specific app, profile, and record type are not affected by this screen, so plan those through page activation instead.
- Save and test on heavy records
Save the setting, then open a record with a long stack of related lists on both desktop and phone. Watch load time and scrolling, and back a page out if performance drops.
The core toggle. Grouped View keeps details and related lists in tabs and sections; Full View shows them together in one scrollable column.
When enabling Full View, choose separately for Desktop and Phone, since the org-default pages and their performance can differ by device.
Full View applies only to pages holding the org default assignment for an object, so the screen lets you opt those specific pages in rather than flipping every page at once.
- Full View is not available in every org. Salesforce gates it for performance, so the option may be missing or limited depending on your configuration.
- Only org-default pages can use Full View. Pages assigned to a specific app, record type, and profile combination keep Grouped View regardless of this setting.
- A single-column layout can feel slow on records with many related lists. Test against your busiest objects before rolling it out widely.
- Grouped View was not retired when Full View shipped. Both remain valid, so treat this as a preference, not an upgrade you must take.
Prefer this walkthrough as its own page? How to Record Page Settings in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Record Page Settings.
Hands-on resources to go deeper on Record Page Settings.
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 the Record Page Settings Setup page let administrators configure?
Q2. Which capability is gated behind Record Page Settings being configured?
Q3. Why do many orgs delay enabling everything in Record Page Settings at once?
Discussion
Loading discussion…