Layout
A Layout in Salesforce is the configuration that decides how fields, related lists, buttons, and actions appear on a record page.
Definition
A Layout in Salesforce is the configuration that decides how fields, related lists, buttons, and actions appear on a record page. The platform runs two layout systems side by side. Page Layouts are the original system that controls the field form, related lists, and actions on a record's detail and edit view. Lightning Pages, built in the Lightning App Builder, control the overall structure of the record page in Lightning Experience, including which components render and where.
Layouts are assigned by profile and by record type, so the same object can show different forms to different users. A Lightning Page typically wraps a Page Layout (or a set of Dynamic Forms field sections) inside its component structure. Compact Layouts and Search Layouts are separate layout types that govern the Highlights panel and list or lookup columns. Most modern orgs configure several of these layers together for a single object.
How the layout systems fit together
Page Layout versus Lightning Page
Page Layout is the original layout system, going back to Salesforce Classic. It defines field placement on the detail and edit forms, the order of related lists, and which buttons and actions are available. The enhanced page layout editor is the drag-and-drop tool Salesforce recommends for this work, and it also sets which elements surface in the Salesforce mobile app. A Lightning Page is the Lightning Experience layout, built in the Lightning App Builder. It controls the whole record page, arranging components like the Highlights panel, related lists, Activity, Chatter, and any custom or third-party components into regions, columns, and tabs. The two systems are not rivals so much as different layers. A Lightning record page often includes a Record Detail component, which renders the assigned Page Layout inside it. So an admin sets the page structure in App Builder and the field form in the page layout editor. Salesforce documents when to reach for each tool: App Builder for page structure and components, the page layout editor for field, related list, button, and action configuration. Knowing which layer owns a given setting saves a lot of confused clicking.
Fields, sections, and field properties
Inside the page layout editor, fields are grouped into sections, and each section can use one or two columns. You drag fields from a palette onto the layout, and valid drop spots highlight in green. Each field on the layout carries two properties that are set at the layout level: Required and Read-Only. These are separate from field-level security, which is set per profile or permission set and decides whether a user can see or edit the field at all. The layout properties only sharpen behavior for fields the user can already access. A field marked Required on the layout must be filled before the record saves, even if the field is not required at the database level. A field marked Read-Only on the layout cannot be edited through that form. Sections also hold the related lists area lower on the layout, where you choose which child records appear and in what order. Because layout properties and field-level security interact, the Field Accessibility view in Setup is handy. It reports the effective behavior for a field across the profile, the field-level security, and the layout, so you can see why a user sees a field a certain way.
Assignment by profile and record type
Page Layouts are assigned through a grid of profile and record type. For each object, you open the page layout assignment screen and pick which layout each profile sees for each record type. The math grows quickly. An object with 8 profiles and 4 record types has 32 assignment cells to manage, and every new profile or record type adds another row or column. This is one reason large orgs feel heavy to administer. When you add a profile, you have to assign layouts for every record type on every object that profile touches, or users fall back to a default that may not fit. Record types are the main lever for showing different forms of the same object, for example a sales opportunity layout versus a renewal opportunity layout. Profiles then refine that per audience. Planning the assignment matrix before you create layouts keeps it manageable. Many teams document the intended profile and record type to layout mapping in a sheet, because the screen itself shows one object at a time and the full picture lives across many screens.
Compact Layouts and the Highlights panel
The Compact Layout is a separate layout type that controls which fields show in the Highlights panel at the top of a Lightning record page. It also drives the key fields in mobile record previews and in expanded lookup cards. A Compact Layout is independent of the Page Layout, so you can carry many fields on the detail form while curating a short list of the most important fields for the Highlights panel. The first field in the Compact Layout often acts as the record's headline. Because the Highlights panel is the most prominent field display a user sees, most orgs configure Compact Layouts deliberately rather than accepting the system default. You assign Compact Layouts per record type, similar to Page Layouts, which lets a renewal record and a new business record highlight different fields. Compact Layouts hold a limited number of fields by design, which forces a useful editorial decision about what truly belongs at the top. Picking the wrong fields here is a common cause of users complaining that a record page feels cluttered or unhelpful, even when the underlying Page Layout is fine.
Dynamic Forms as the modern direction
Dynamic Forms move the fields and sections off the classic Page Layout and onto the Lightning Page itself, as individual components in the App Builder. When Dynamic Forms is enabled for an object, the component panel gains a Fields tab with a Field Section component and a list of the object's fields. You place Field Section components anywhere on the page, then drop fields inside them, spreading the form across columns and tabs instead of one long block. The big advantage is visibility rules. You can show or hide a field or a whole section based on record data, the user, or the device, which the classic Page Layout cannot do at the field level. Dynamic Forms is supported for most, but not all, standard objects, plus custom objects. If you open a record page in App Builder and do not see a Fields tab, the object does not support Dynamic Forms yet. Salesforce positions Dynamic Forms as the path forward, so new builds should usually start there. Classic Page Layouts still work and still control field-level security interactions, related lists, and actions, so the two approaches coexist during the migration.
Search Layouts and other layout types
Search Layouts are a distinct layout type that controls which columns appear in list views, search results, lookup dialogs, and related list columns in Classic. Each object has its own Search Layouts, configured separately from the Page Layout. Good Search Layout choices matter for daily usability. If the columns a user needs to scan are not in the search results, they have to open each record to find the right one, which slows everyone down. Beyond Page, Compact, and Search Layouts, the platform has a few more layout flavors worth knowing. Mini Page Layouts control the hover details and inline edit window in Classic. Feed-based layouts existed for Chatter-heavy record pages. The point is that the single word "layout" covers a family of configurations, not one screen. When someone reports that a field is missing, the first diagnostic question is which layout they mean: the detail form, the Highlights panel, the list view columns, or the Lightning page structure. Naming the right layer turns a vague complaint into a quick fix, because each layer is edited in a different place in Setup.
Deploying and managing layouts as metadata
Layouts are metadata, so they move between orgs through change sets, the Salesforce CLI and source format, or managed and unmanaged packages. The layout definition itself deploys cleanly, and so does the assignment of which profile gets which layout for which record type. In practice, large reassignments are sometimes finished in the target org for safety, because a bad assignment can hide fields from many users at once. Treat layout changes like any other user-facing release. They touch the screen people work on all day, so a small mistake is highly visible. A field accidentally removed from a layout looks to users like the data is gone, even though it is still in the database. Version control your layout metadata, review diffs before deploying, and avoid editing production layouts by hand unless your change-management policy allows it. When you adopt Dynamic Forms, remember that the field configuration now lives in the Lightning Page metadata rather than the Page Layout, which changes what you deploy. Keeping a clear record of which objects use Dynamic Forms versus classic layouts prevents surprises during a release, especially in orgs midway through the switch.
How to customize a page layout
Editing a record's field form is the most common layout task. Here is the path for the enhanced page layout editor, which Salesforce recommends over the original editor. The steps assume Lightning Experience and an object you have permission to customize.
- Open the object's layouts
In Setup, use the Object Manager, open the object, then select Page Layouts. Click the layout you want to edit, or click New to create one based on an existing layout.
- Place fields and sections
Drag a Section element onto the form to group fields, then drag fields from the palette into it. Valid drop spots highlight in green. Set each field's Required and Read-Only properties using the wrench icon.
- Configure related lists, buttons, and actions
Scroll to the Related Lists area and add or reorder the child objects to show. Use the Buttons and Mobile and Lightning Actions sections of the palette to control which actions appear on the page.
- Save and assign the layout
Click Save, then use Page Layout Assignment to map this layout to the right profiles and record types. Repeat per record type so each audience sees the intended form.
Forces the field to be filled before saving through this form, on top of any database-level requirement.
Prevents editing the field on this form for users who would otherwise have edit access via field-level security.
Chosen separately from the Page Layout; it controls the Highlights panel fields and mobile previews per record type.
For supported objects, you can migrate the page layout fields onto the Lightning Page in App Builder for column, tab, and visibility-rule control.
- Layout Required and Read-Only are not the same as field-level security. A field hidden by field-level security never appears, no matter what the layout says.
- New profiles do not auto-inherit your layout. Until you assign a layout per record type, those users may land on a default layout that omits fields they need.
- Removing a field from the layout does not delete the data. The value stays in the database and can still be set by automation, imports, or the API.
Prefer this walkthrough as its own page? How to Layout in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Page LayoutsSalesforce
- Deciding When to Use Lightning App Builder or the Page Layout EditorSalesforce
Straight from the source - Salesforce's reference material on Layout.
- Break Up Your Record Details with Dynamic FormsSalesforce
- The Enhanced Page Layout EditorSalesforce
Hands-on resources to go deeper on 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. What does a classic Page Layout control on a record's detail and edit views?
Q2. Why does a larger org with many profiles and record types face growing administrative effort around Page Layout assignment?
Q3. Which Lightning feature gives field-by-field placement and conditional visibility beyond what a classic Page Layout offers?
Discussion
Loading discussion…