When to Use Record Types vs. Page Layouts?

Share this article...

Learning core Salesforce concepts is a fundamental step to becoming a well-rounded professional. Standard features such as Record Types and Page Layouts can be used in conjunction with one another to create fantastic customized experiences for your users. 

But what are the differences? When should you use one over the other? This article will dive into the differences between these two features, as well as walk through a few different examples to ensure you’re ready to delight your users! 

Page Layouts

Page layouts determine which fields are displayed to your users on a record. They allow you to add fields, sections, links, and custom buttons, as well as a few other features.

Many Page layouts can be created and applied to different groups of users, with the goal of creating a customized experience. You could have one Account record e.g. Acme Corp, but with different information showing depending on your user profile.

It’s important to note that you can only apply one page layout to one group of users per object, per record Type. For example, if you have one record Type on the Accounts object, you can only apply one page layout per profile. Record types come into play to extend this.

Record Types

Record types let you offer different business processes, picklist values, and Page layouts to different users. 

For example, one of the most common use cases of record Types would be to create two different sales processes on the Opportunity object – each with different sales stages and Page layouts.

This means that with record Types you can now apply multiple Page layouts per object, per user profile. 

READ MORE: Record Type, or Not? 6 Questions to Ask When Planning Salesforce Record Types

Lightning App Builder & Dynamic Forms

When Salesforce Classic was the only UI around, Page layouts and record Types were some of the most powerful ways to customize user experiences.

However, with the introduction of Salesforce Lightning, a new wave of features have been released to customize Salesforce even further. In some cases, this means you won’t need to create a new page layout or record type anymore, saving a lot of legwork and potential scalability issues.

Lightning App Builder: This is the page that houses your detail page layout (described above). You are able to drastically customize the look and feel of the entire page using this tool.

READ MORE: Lightning App Builder

Dynamic Forms: This fantastic feature allows you to display clusters of fields, separate from the main page layout. This feature is the first of its kind and has huge potential to disturb the way we build experiences for our users.

READ MORE: Salesforce Dynamic Forms – Overview & Deep Dive Tutorial


Example A: Support users are being onboarded onto Salesforce. They are required to view an extensive amount of information on Accounts around the customer’s technical solution. This information does not apply to any existing users. They have two Support profiles.

With this example, we have quite a straightforward use case. As support users are now being brought onto the system, they need to see different information than others. As we are only dealing with one additional view for a group of users, we can use one additional page layout and apply this to both support profiles.

Example B: Sales are now selling into Enterprise accounts, and as such, have a different lead process that needs to be implemented. At this stage, Sales only require different Lead statuses. They have two Sales profiles.

There are a few criteria to look at when evaluating whether to use a record type or not. As the requirement above mentions a lead process change, we will automatically need to use a record type. There is no mention of any field changes, so we can easily apply a single record type to the two profiles.

Example C: Sales have yet another requirement (*Sigh*) – they would like to implement a different selling process on Opportunities for each of their three tiered levels of accounts (1-100, 101-500, 501+ employees). This involves different stages that the sale moves through, as well as capturing different information along the way. They only have one Sales profile.

Here’s a more exciting requirement. We can see that different processes are mentioned straight away, therefore record types are going to have to be used. The requirement also mentions that there are three different selling processes. As we can only assign one sales process to one record type, we will need to create three! In addition to this, they would also like to capture different data for each sales process. This will require three page layouts (in addition) to be assigned to each record type.

Example D: The support team has a requirement to show different information on the page layout, depending on which level the case has been escalated to (Tier 1, 2, or 3). The support agents have three different profiles which correspond to the escalation level. 

The requirement seems to be straightforward as they have directly mentioned the need for different page layouts – because of the three tiers we know we will need three page layouts. The fact that we actually have three different profiles conveniently set up means that we can just assign each page layout to each profile. However, if we only had one profile here, we would need record types in order to meet the requirement (with some automation to change record types based on escalation!).


You should now be well on your way to understanding the key differences between record types and page layouts in Salesforce, as well as how and when to use each feature.  

12 thoughts on “When to Use Record Types vs. Page Layouts?

  1. Great article! I don’t understand on scenario A why you’d use one page layout and one record type? Are you going to turn off the unneeded fields using field-level security for one set of users?

    1. Hi Peter, thanks for your kind words. On the first example we only need to use a page layout because we are only concerned with new fields for support users. We can simply have a “normal” layout and then a “support” layout, these can be applied to the relevant profiles and voila!

  2. Hey Ben,

    How do we go with this scenario :
    “Sales reps can modify fields on an opportunity until it is closed. Only the sales operation team can modify the post closed follow-up dates and post closed follow-up comments fields.”

    If I consider there are 2 different profiles, in above example until the Oppo record is closed, both profile users can modify the record(this can be done by assigning same recordtype – pagelayout to both profiles) wherein when it moves to Closed, I need to change the pagelayout as 2 additional fields for follow-up will appear on layout and only should be editable to operation team.

    My view – Once its moved to Closed, I will update the recordtype to some new recordtype which has 2 follow-up fields and I make sure Sales rep team doesnt have access to that recordtype, so they would still see the pagelayout of default recordtype and Operation team can do their follow up activity with new recordtype.

    Please correct me if above approach is wrong.

  3. Hi there, thank you for this helpful article. For scenario D what type of automation would you use to ensure that the correct record type is shown for the corresponding level of escalation?

  4. For example D. I dont see that you need Lightning pages. You could meet the requirement using Classic page layouts in exactly the same way.

Add Comment