Introduction

The record page problem in Salesforce rarely starts with bad intentions. Someone needed a field tracked, someone else needed visibility into a related object, a third team had a compliance requirement, and each of those was a completely legitimate ask. The problem is that nobody was looking at the cumulative effect on the person who has to open that record fifty times a day.

How to Design a Salesforce Page Layout for Lightning

The core problem is almost always the same. The page layout hasn't kept up with how the org actually works.

This guide covers everything you need to know about Salesforce page layout customization, how classic page layouts work, when to use them versus Lightning Record Pages, and how to use the Lightning App Builder to design purposeful, role-specific interfaces that actually improve adoption.

What Is a Salesforce Page Layout?

A Salesforce page layout controls what users see and interact with when they open a record. Specifically, it determines which fields appear on the detail and edit views of a record, how those fields are arranged and grouped into sections, which related lists are shown (and in what order), and which buttons and quick actions are available.

Page layouts are assigned to users through their profile, combined with the record type of the record they're viewing. This means the same object, say, an Opportunity, can show an entirely different set of fields to a Sales rep versus a Finance approver, as long as they're on different profiles or working with different record types.

What Page Layouts Control

  • Field visibility, arrangement, and grouping into sections
  • Field properties: required, read-only, or editable
  • Related lists and their column display
  • Quick actions, standard, and custom buttons
  • Compact layouts (the fields shown in the Highlights Panel)

What Page Layouts Don't Control

Page layouts do not control the overall structure of the page, meaning they can't dictate where a related list appears relative to a chart component, or whether a custom Lightning Web Component (LWC) appears on the right sidebar. That's the job of Lightning Record Pages, which are built separately in the Lightning App Builder.

Page Layouts vs. Lightning Record Pages: Understanding the Difference

This is the most common source of confusion for Salesforce admins and business users alike, so it's worth addressing clearly.

AspectsPage LayoutLightning Record Page
What it controlsFields, related lists, buttonsFull page structure and components
Built withPage Layout EditorLightning App Builder
Assigned byProfile + Record TypeApp + Profile + Record Type
Supports custom componentsNoYes
Conditional visibilityNoYes (via Dynamic Forms)
Works in Salesforce ClassicYesNo
Supports mobileYesYes (with Dynamic Forms enabled)
The page layout is a component that sits inside a Lightning Record Page. Specifically, it populates the "Record Detail" component on a Lightning page. When you click a record and see its fields, you're looking at either the page layout rendered within a Lightning page or a Dynamic Forms configuration that has replaced it.

A Lightning Record Page, in contrast, is the entire canvas. It controls headers, tabs, sidebars, the activity timeline, reports, charts, and any custom components you want to surface alongside those fields.

The Three Types of Lightning Pages in Salesforce

The Lightning App Builder is where all Lightning pages are created and managed.

There are three page types:

1. Home Page

The landing page users see after logging in. Useful for surfacing charts, dashboards, announcements, recent records, and task lists. Assign different Home Pages to different profiles so a Sales Manager sees pipeline metrics while a Support Agent sees open case queues.

2. Record Page

The most heavily used type. A Record Page is what appears when a user opens a specific record, like an Account, Opportunity, Lead, Case, and so on. This is where thoughtful layout design has the most impact on daily productivity.

3. App Page

A standalone page assigned to a specific Salesforce app. Useful for building command-center dashboards or consolidated views that aren't tied to a single record.

Page Layout Customization: The Classic Editor

Before moving into Lightning pages, it's worth understanding what you can do directly in the classic Page Layout editor because it still powers many things, even in Lightning orgs.

How to Edit a Page Layout

Go to Setup → Object Manager → [Object] → Page Layouts, then click the layout you want to edit. This opens the drag-and-drop editor.

From here you can:

  • Drag fields from the palette into sections on the layout
  • Create new sections and choose one-column or two-column display
  • Set fields as read-only or required at the layout level (independent of field-level security)
  • Add related lists and configure their displayed columns
  • Add quick actions to the Salesforce Mobile and Lightning Experience actions bar

Layout Strategy: What Most Orgs Get Wrong

The most common page layout mistake is treating the layout as a field dump. Every field that might ever be relevant ends up on the layout, "just in case." This creates pages with 40+ fields that overwhelm users, slow data entry, and reduce adoption.

A better approach is to design layouts by role and stage. Ask: What does a Sales rep actually need to see and enter when they first qualify a lead? That's very different from what a Sales Manager needs when reviewing a won deal for forecasting. You’ll get different answers for different layouts.

Practical rules for better field organization:

  • Put the most critical 5–8 fields at the top, above the fold
  • Group fields logically, not alphabetically. Cluster contact info together, financial fields together, status fields together
  • Use section labels as navigation cues, "Deal Information," "Billing Details," "Internal Notes," to communicate intent.
  • Remove fields that users never update from the layout. They can still exist on the object, but they don't need to be on every layout.

Lightning Page Design in the App Builder

Once your page layout handles the field layer, the Lightning App Builder handles everything else. This is where page layout in Salesforce becomes genuinely powerful.

Choosing a Page Template

When creating or editing a Lightning Record Page, your first decision is the template, the structural skeleton of the page. Common options include:

  • Header and Right Sidebar: Main content area with a narrower column on the right. Good for most Record Pages
  • Two Equal Regions. Two equal-width columns. Useful when you want four columns of fields by placing field sections in each column (a tip: this is the only way to get a 4-column field layout in Salesforce Lightning, compared to the 2-column maximum in a standard page layout)
  • Header and Three Regions: Gives maximum flexibility for complex records like Accounts or Cases.

Key Components to Know

The component library in Lightning App Builder includes both standard and custom components. The most strategically important standard ones:

  • Highlights Panel: The strip of key fields at the top of every record. Controlled by the object's Compact Layout. Update the Compact Layout in Setup → Object Manager → [Object] → Compact Layouts to change what appears here. Put your 4–6 most decision-critical fields here.
  • Record Detail: Renders the assigned page layout's fields. This is the "classic page layout inside a Lightning page" view. If you haven't adopted Dynamic Forms yet, this is what controls your field display.
  • Related Lists and Related List - Single: Display associated records from related objects. Related list configuration (which columns appear, in what order) is still controlled by the page layout's related list settings.
  • Tabs component: Lets you organize record content into tabs, dramatically reducing visual clutter. Instead of a page that scrolls endlessly, you can have a "Details" tab, "Activity" tab, "Documents" tab, and so on. This is one of the most impactful usability improvements an admin can make.
  • Report Charts: Surface an embedded Salesforce report chart directly on a record page. For example, embedding a pipeline trend chart on the Account record gives Sales Managers context without leaving the record.
  • Rich Text: Place a static banner or note on the page. Useful for compliance reminders, process guidance ("Check pricing approval before Stage 4"), or contextual instructions.

Dynamic Forms: The Bridge Between Page Layouts and True Flexibility

Dynamic Forms is the most significant evolution in Salesforce page layout customization in recent years. It effectively replaces the "Record Detail" component, the monolithic block of fields from your page layout, with individual, independently configurable field and section components.

What Dynamic Forms Enable

With Dynamic Forms enabled on a record page:

  • Individual fields and sections can be placed anywhere on the page, not just within the Record Detail block
  • Visibility rules can be applied to individual fields and sections, show a "Competitor Information" section only when Deal Stage is "Proposal/Price Quote", or hide a "Legal Review Required" field unless Deal Value exceeds $50,000
  • You can reduce the number of page layouts you maintain, since conditional visibility handles the variation that previously required separate layouts for separate profiles.
  • Page load performance can improve by placing fields inside accordion or tab components, which load content on demand rather than all at once

How to Enable Dynamic Forms

  1. Open the record page in the Lightning App Builder
  2. Click the Record Detail component
  3. In the properties panel, click Upgrade Now to launch the Dynamic Forms migration wizard.
  4. Select the page layout to use as a migration source and click Finish

After migration, a Fields tab appears in the App Builder component panel. From here, you drag individual Field Section components and fields anywhere on the page.

Important limitations to know:

Dynamic Forms are not supported on all objects. Campaigns, Tasks, and Products (which are not LWC-enabled) still rely on standard page layouts.

If you open a record page in the App Builder and don't see a Fields tab, Dynamic Forms isn't available for that object. Also note: related lists are still controlled by the standard page layout, not by Dynamic Forms, so keep your page layouts updated accordingly.

When to Use Page Layouts vs. Lightning Pages

Use a classic page layout when:

  • Your org is still on Classic, or you're supporting a mixed Classic/Lightning environment
  • You just need to control field visibility and arrangement without components
  • The object doesn't support Dynamic Forms (Campaigns, Tasks, Products)
  • You want to configure related list columns and buttons

Use a Lightning Record Page with Dynamic Forms when:

  • You want component-level control over the full page with charts, related lists, custom components, alongside fields
  • You need conditional visibility on fields or sections without creating multiple page layouts
  • You want to assign different page experiences by app, profile, and record type independently
  • You're building mobile-friendly record pages (Lightning pages are mobile-responsive)

For most orgs on Salesforce Lightning today, the best practice is to migrate toward Lightning Record Pages with Dynamic Forms for complex objects and keep standard page layouts for simpler objects or those not yet supported by Dynamic Forms.

How MassMailer Supports Salesforce Page Layout Design

A well-designed Salesforce page layout puts the right information in front of the right person at the right moment. However, the moment a user needs to act on that information, like sending a follow-up, reaching out to a contact, or running a campaign, Salesforce's native email capability introduces friction that no amount of layout design can fix. This is where MassMailer fits in.

The Limitations of Native Salesforce Email

Before understanding what MassMailer adds, it helps to be specific about where Salesforce falls short on its own.

The 5,000 emails per day cap:

Salesforce limits outgoing external email to 5,000 per org per day across all editions. For individual reps sending one-off emails, this is rarely an issue. However, for any team running campaigns, even modest ones, from Contact, Lead, or Campaign record layouts, this ceiling arrives fast.

When it does, teams are forced to ration sends, stagger campaigns across days, or move to a separate platform. Any of these outcomes breaks the Salesforce-first workflow your layout is designed to support.

Shallow activity logging:

When a user sends an email from a Salesforce record natively, the activity log records one data point: email sent. It does not tell you whether the recipient opened it, clicked a link, bounced, or unsubscribed.

The Activity Timeline, which you place prominently on every record page, is one of the most valuable components for reps and managers alike, but it shows an incomplete picture.

A layout designed to surface a full communication context cannot do its job when the underlying data is that thin.

No engagement tracking on templates:

Salesforce Lightning Email Templates offer a solid no-code building experience, but they do not natively track open rates, click-through rates, or bounce data at the individual record level.

A sales rep using a template to follow up on an Opportunity has no visibility into whether that email was ever opened, which matters enormously for timing the next step.

How MassMailer Addresses Each Limitation

1. Unlimited sends, any volume:

MassMailer removes the 5,000/day ceiling entirely. Teams can send at whatever volume their campaigns require without planning around Salesforce's cap or moving outreach to an external platform.

For teams whose page layouts are built around Campaign or Contact records as the center of their workflow, this means email volume is no longer a constraint on how they use those layouts.

2. Engagement tracking at the individual record level:

MassMailer tracks opens, clicks, bounces, and unsubscribes per contact, per record. A sales rep viewing an Opportunity layout can see not just that an email was sent, but that it was opened three times and a specific link was clicked. That data informs the next action without leaving the record page.

3. Send from any standard or custom object:

MassMailer is not restricted to Contact and Lead objects. It works on any standard or custom object in your Salesforce org.

If you have invested in building page layouts for a custom renewals object, a membership object, or a projects object, MassMailer lets users send and track emails directly from those records. The layout becomes a full workspace rather than a read-only view.

4. Flow-triggered drip campaigns with tracking:

MassMailer integrates with Salesforce Flow to trigger automated email sequences based on field changes. When an Opportunity Stage changes, when a Contact Status updates, when a date field is reached, MassMailer can fire the next email in a sequence, track its engagement, and write results back to the record.

The stage field or status picklist already on your page layout becomes the trigger for an entire automated communication workflow, without any external automation platform.

5. Email verification for cleaner record data:

MassMailer Verifier checks the email addresses stored against your Salesforce records and flags invalid ones before they generate bounces.

The email field that your page layout prominently displays, one of the most critical fields on a Contact or Lead record, becomes more reliable as a result. Better data quality on the record feeds better deliverability in your campaigns.

Conclusion

Every layout decision is also a data quality decision, even when it does not feel like one. The order of fields on a page influences which ones get filled in. The placement of a section below the fold determines how often it gets scrolled to. A required field with no context about why it is required gets populated with junk values just to clear the save button. A related list with too many columns gets ignored because it takes too long to parse.

Poor data quality in Salesforce is rarely caused by users who do not care. It is caused by layouts that make doing the right thing harder than doing the easy thing. When the path of least resistance aligns with the correct behavior, when the most important fields are the first ones users see, when sections group information in the order a process actually unfolds, and when required fields appear at the moment they are relevant, data quality improves without a training program or a governance policy.

This is why layout design deserves a seat at the data strategy table. Before you build another validation rule or write another process document about CRM hygiene, look at the layout.

Better page layouts get your team to the right information faster. MassMailer gets them to the right action faster. Together, they make Salesforce the only tool your team needs to open, understand, and act on every customer relationship, without switching tabs, exporting lists, or manually updating records after the fact.

Book a demo. Start your free MassMailer trial at MassMailer.io.