Page Layout Design Guidelines

Page Layout Design Guidelines provide standards for when to create new page layouts and how to name them. They also provide guidelines for organizing buttons, actions, sections, fields, custom links, and related lists.

Creation

Nimble AMS includes page layouts for every object, and administrators can directly edit them. Additionally, some Nimble AMS objects that use record types already include a page layout for each record type.

Therefore, the only scenarios in which you generally need to create a new page layout are when you created a new record type for an object and none of the page layouts display the desired combination of buttons, sections, fields, or related lists.

If a page layout exists that includes the desired configuration but there is already a unique page layout created for each of the other record types, we recommend continuing that pattern by creating a new page layout specifically for your new record type.

An advanced use of page layouts is to also create a page layout for specific profiles. Unlike compact layouts, you can assign page layouts to a specific record type and also to a specific profile, simultaneously. This requires more maintenance but, when executed effectively, creates a very clear and efficient user experience.

Naming

The standard for naming a page layout depends on whether the page layout is used as a default for all records or if it is assigned to a specific record type. In both cases, title case is used.

Learn more about title case in Component Design Guidelines.

Default Page Layouts

For a page layout that is not assigned to a specific record type, enter a name in title case with the format:

For example, Order has no record types and therefore has a single page layout named Order Layout.

Record Type Page Layouts

For a page layout assigned to a specific record type, enter a name in title case with the format:

For example, the Product record type Donation has a page layout assigned to it named Donation Product Layout.

Actions and Buttons

Remove any standard actions and buttons that are unused. This varies for each object. Common examples are:

• Change Owner
• Change Record Type
• Sharing
• Submit for Approval
  

When Record Type is included on the page layout as a field, staff can change the record type from that field, so you do not need to include Change Record Type.

Across page layouts, maintain as much consistency as possible by placing common actions and buttons in the same sequence. For example, always start with Edit and Delete.

The Highlights Panel only displays the highest ranked actions before relegating the rest to a dropdown menu. To maintain efficiency in the user experience, we recommend editing the record page to expose all frequently used actions. Learn more about Record Page Design Guidelines.

Maintain inheritance for the Salesforce Mobile and Lightning Experience Actions area unless you need to:

• Include actions that are not available as buttons
• Change the sequence of actions in a way that is not possible in the Standard Buttons and Custom Buttons area

Sections

With page layouts, administrators can create and rearrange sections to better organize groups of fields.

Sequence

Always leave the standard Information section as the first section of the page layout, with its default configuration: 2-column, Top-Down tab-key order, and with the header visible on the Edit Page only.

Always leave the System Information section as the final section of the page layout. Change the default configuration so the section header is visible on the Detail Page. This prevents System Information fields from appearing directly below fields in the preceding section.

Between the Information and System Information sections, optionally create additional sections to logically group related fields together. Place these additional sections in sequence so that important sections are before less important sections.

Naming

Name section headers as simply as possible, ideally with a single word. Exclude unnecessary words such as "Detail."

Examples:

• Accounting
• Address
• Contact
• Demographics
• Description
• Membership

Layout

Use the 2-Column Layout unless a section contains text area (long or rich) fields. Place text area (long or rich) fields in a 1-Column Layout.

If you want a text area (long or rich) field(s) in a 1-Column Layout section to appear adjacent to fields in a 2-Column Layout section:

1. Place the 1-Column Layout section adjacent to the 2-Column Layout section.
2. For the section that is lower on the page layout, hide its section header from the Detail Page and Edit Page.

Tab-Key Order

Use the Top-Down tab-key order, which is the default for all standard object page layouts.

Number of Fields

Place at least one field in each section. If a section exceeds twelve fields, consider adding blank spaces or dividing the section into two sections.  

Field Placement

Unlike other layouts, page layouts are intended to display all of an object's fields, not just the most important fields. While field sequence is very important for other layouts, it is not as important in page layouts, where you can change the section sequence and display an unlimited number of fields.

However, there are some general standards regarding field placement that we recommend to improve the user experience.

Placement within a Section

Within a section, identify if fields can be logically grouped into smaller sub-sections. Examples of sub-sections:

• Start Date and End Date
• Status and Status Flag

In general, keep the fields of a sub-section together in the same column of a 2-Column Layout. The space between the two columns is larger than the space between two adjacent rows, so each column appears in the user interface as two sub-sections. Place the first sub-section in the left column and place the next sub-section in the right column, with the goal of keeping the field count in each column as balanced as possible. This prevents excessive whitespace and the need to scroll. For example:

• In the left column, place Start Date followed by End Date. This is the first sub-section.
• In the right column, place Status Flag followed by Status. This is the second sub-section.

Similar fields can span both columns if there are no sub-sections—that is, if the section cannot be subdivided any further. For example, in a section named Term that only contains Start Date and End Date, place Start Date in the left column and End Date within the same row, in the right column. This prevents excessive whitespace and the need to scroll.

If there are multiple sub-sections in the same column, you can separate them with a blank space.

Placement Consistency

Some fields appear on many objects, such as Record Type, Entity, and Status. We recommend consistently placing these fields in the same section and column across all page layouts, but not at the expense of clarity or efficiency.

Examples:

• If the object uses Name with the Text data type, always place it in the Information section, at the top of the left column.

  

  Do not include the Name field when it is configured with the Auto Number data type. It cannot be edited and is already displayed at the top of the page.

• Place Record Type in the Information section, at the top of the right column.
• Place status fields in the Information section, in the right column.
• If there is an Accounting section and an Entity field, place it in the right column. 
• Place alternate name or additional name fields in the Information section, in the left column.

Custom Links

Custom links can be placed in up to three columns. Balance the number of links in each column to prevent excessive whitespace and the need to scroll. For example, to place four custom links:

1. Place the first custom link in the first column.
2. Place the second custom link in the second column.
3. Place the third custom link in the third column.
4. Place the fourth custom link in the fourth column, below the first custom link.

Related Lists

With page layouts, administrators can add and rearrange related lists to display records related to the current record.

Sequence

Place related lists in the following sequence, skipping any that do not exist for the object:

1. <all related objects, in alphabetical order>

   

   For Account page layouts, we recommend placing Affiliation related lists first. Place Parent Affiliations before Child Affiliations if the page layout includes both.

2. Files

3. Notes

   

   If records include legacy notes and/or attachments, also add the Notes & Attachments related list. However, we recommend migrating to Files and Notes. Learn more about Changes to the 'Notes and Attachments' related list (external).

4. Open Activities
5. Activity History
6. <object name> History

Overriding Fields and Sort Order

The default fields for related lists on page layouts are determined by the Tab search layout. If the administrator has not edited the properties of a related list, it will actively inherit the settings of the Tab search layout.

To change the fields on a related list, we recommend maintaining this inheritance by editing the Tab search layout of the related object. Learn more about Search Layout Design Guidelines.

However, you will need to override a related list's inheritance of the Tab search layout if:

• The object has multiple page layouts and each page layout needs to display different related list fields.
• The related list's default Sort By and/or sort direction (ascending/descending) needs to be changed.
  • For example, the Orders related list can be changed to sort by Transaction Date descending.