Page Layout
A Page Layout in Salesforce is the configuration record that controls how a specific record type appears in the Salesforce UI.
Definition
A Page Layout in Salesforce is the configuration record that controls how a specific record type appears in the Salesforce UI. The Page Layout decides which fields show up on the record detail page, what order those fields appear in, which sections group them, which fields are required versus read-only, which related lists render below the detail section, and which buttons and quick actions surface on the page. Every record type on every object has a Page Layout assignment per Profile, and the combination of Profile and Record Type decides which Page Layout a given user sees when they open a given record.
Page Layouts are the original UI customization mechanism in Salesforce. The platform shipped with them in the early Classic UI, and most enterprise orgs accumulated dozens of them over the years: one per major Profile per Record Type per object. The proliferation is part of the design (different users need different views) and part of the maintenance pain (a new field requires touching every Page Layout that should display it). In Lightning Experience, the Page Layout still exists but has been mostly supplemented by Lightning Record Pages, which are a separate configuration layer that can override or augment what the Page Layout produces.
How Page Layouts compose with Lightning Record Pages and Compact Layouts
Page Layout vs Lightning Record Page
Page Layout and Lightning Record Page are two different concepts that confuse newer admins. The Page Layout controls field placement, required fields, read-only fields, related lists, and quick actions; the Lightning Record Page (built in Lightning App Builder) controls the overall page composition: which components appear, where they sit, which tabs the page has, and which components conditionally show or hide. The Lightning Record Page can include a Record Detail component that renders the Page Layout's field configuration, so the two layers compose: Page Layout for field-level configuration, Lightning Record Page for page-level composition. Most newer orgs build Lightning Record Pages first and treat Page Layouts as a backing store for field configuration.
Assignment matrix
Page Layout assignment per Profile per Record Type is where the matrix complexity lives. A typical Salesforce org has five to ten Profiles, three to five Record Types per object, and one Page Layout per Profile per Record Type. Multiply across all objects with custom Page Layouts and you get hundreds of Page Layout assignments to maintain. Setup > Object Manager > [object] > Page Layouts > Page Layout Assignment shows the matrix. Most admins build a parent Page Layout (Master) and clone variants for specific Profiles, which keeps the configuration manageable. Some orgs use Permission Sets to override Page Layout assignments per user, which adds another dimension to the matrix but lets you handle one-off cases without inventing new Profiles.
Required and Read-Only fields
Required and Read-Only field settings on Page Layout are the second-most-common cause of save errors after Validation Rules. A field marked Required on the Page Layout prevents save when blank; a field marked Read-Only prevents the user from editing it through the UI. Both settings layer on top of field-level security from Profile and from field definitions. The order of evaluation matters: field-level security in Profile/Permission Set governs whether the user can see and edit the field at all; Page Layout settings govern whether the field is required or editable on this specific layout. A field that is Required on Page Layout but hidden through Profile FLS produces an unsaveable record, which is one of the more frustrating bugs to debug in Salesforce.
Related Lists
Related Lists on Page Layout control which child records appear below the detail section on the record page. By default, every child object that has a relationship to the parent shows up; admins can add, remove, and reorder Related Lists per Page Layout, and configure which fields the Related List displays. The Related List configuration also lets you sort, filter, and add custom buttons to each Related List. Most Page Layouts have between three and seven Related Lists, with the high-traffic child objects (Activities, Files, Contacts under Account) higher up the page than the rarely-touched ones (Notes, Approval History).
Quick Actions and Lightning Actions
Quick Actions on Page Layout are the buttons that surface on the record page for quick record-creation actions. New Task, New Event, Log a Call, New Case, and any custom quick actions get added to the Page Layout's Mobile and Lightning Actions section. The Actions section is what powers the Activity composer's tab order on Lightning record pages, so adding or reordering Actions changes the user experience directly. Most enterprise orgs limit Quick Actions to the most-used five or six per record type; piling on more actions makes the composer cluttered and harder to navigate.
Buttons section
Buttons section on Page Layout controls which standard and custom buttons appear in the top-right of the record page. Edit, Delete, Sharing, Clone, Submit for Approval, and any custom buttons configured at the object level show up here. Most orgs hide buttons that should not be available to specific Profiles (Delete is usually hidden from sales reps on Account; Submit for Approval is shown only on records that go through approval flow). The button list is per Page Layout, so different Profiles can see different button sets on the same record.
Compact Layout
Compact Layout is a separate concept from Page Layout that controls the highlight panel at the top of a Lightning record page. The Compact Layout decides which up-to-ten fields appear in the highlight, regardless of what the full Page Layout shows. Most orgs configure compact layouts independently from Page Layouts: the Compact Layout surfaces the four to seven most important fields for quick reference, while the Page Layout below shows the full detail. Compact Layouts are also what Salesforce mobile apps use as the record header, so any mobile-heavy team should configure their Compact Layouts carefully.
How to edit a Page Layout
Editing a Page Layout is one of the most-frequent admin tasks. Most Page Layout changes are small (add a new field, reorder a section), but the cumulative impact of these changes is large because every user sees them immediately on next page load.
- Open Setup and navigate to the Page Layouts for the object
Setup > Object Manager > select the object > Page Layouts. The list shows every Page Layout on the object, with the number of users assigned to each one.
- Open the Page Layout you want to edit
Click the layout name to open the layout editor. The editor shows a palette of available fields at the top and the live layout below.
- Add or rearrange fields
Drag fields from the palette to the layout. Drag fields within the layout to reorder them. Drag sections to add new sections or reorganize the page structure.
- Set Required and Read-Only flags
Hover over a field in the layout to surface the wrench icon, then toggle Required and Read-Only as needed. Required prevents save when blank; Read-Only prevents UI edits.
- Configure Related Lists and Actions
Scroll to the Related Lists section and add or remove the child objects that should appear. Scroll to the Mobile and Lightning Actions section and configure the Quick Actions and global actions.
- Save and assign
Click Save. Then go to Page Layout Assignment to confirm which Profile and Record Type combinations use this layout; assign explicitly if needed.
- Test with a representative user
Log in as a user assigned to this Page Layout (or use Login As) and confirm the layout renders correctly. New fields, required fields, and removed sections all show up at this step.
Set on Page Layout, validated on save. Different from Validation Rules; both fire on save but Required is simpler and surfaces a clearer error.
Locks the field on the UI; can still be set programmatically through Flow or Apex. Useful for system-of-record fields that downstream automation maintains.
- Page Layout Required is layered on top of field-level security. A field hidden through FLS but marked Required on Page Layout produces an unsaveable record; ensure FLS aligns with Page Layout requirements.
- Page Layouts assigned per Profile per Record Type. Forgetting to assign a new layout means users default to the Master layout, which is usually not what you want.
- Lightning Record Pages can override Page Layout behavior in Lightning Experience. If your Lightning Record Page does not include the Record Detail component, the Page Layout's field configuration is invisible to users.
- Compact Layout is separate from Page Layout. Editing the Page Layout does not change the highlight panel at the top of the record page; that lives on Compact Layout.
Trust & references
Cross-checked against the following references.
- Page LayoutsSalesforce Help
- Lightning App BuilderSalesforce Help
Straight from the source - Salesforce's reference material on Page Layout.
- Page LayoutsSalesforce Help
Hands-on resources to go deeper on 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. Can a Salesforce admin configure Page Layout without writing code?
Q2. What is the primary benefit of Page Layout for Salesforce administrators?
Q3. Why is understanding Page Layout important for Salesforce admins?
Discussion
Loading discussion…