When to use Record Types Vs Page Layouts?

Share this article...

Learning core Salesforce concepts is a fundamental step in becoming a well-rounded professional. Standard features such as Record Types & 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! 

“Mogli”

Page Layouts

Page Layouts determine which fields are displayed to your users on a record. They allow you to add fields, sections, links, custom buttons, and 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. 

Further Reading: 6 Questions to Ask When Planning Salesforce Record Types

Lightning App Builder & Dynamic Forms

When Salesforce Classic was the only UI around, Page Layouts & Record Types were one of the most powerful way to customise user experiences.

However, with the introduction of Salesforce Lightning, a new wave of features are being 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 leg work and potential scalability issues.

Lightning App Builder – This is the page that houses your detail page layout described above. You are able to drastically customise the look and feel of the entire page using this tool. Read more…

Dynamic Forms – Dynamic Forms is a fantastic new feature that allows you to display clusters of fields, separate from the main page layout. This feature is the first of it’s kind and has huge potential to distrub the way we build experiences for our users.

Further Reading: Salesforce Dynamic Forms – Overview & Deep Dive Tutorial

Examples

A – Support users are being onboard 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.

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.

C – Sales have yet another requirement *Sigh*..they would like to implement a different selling process on Opportunities for each of their 3 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 3 different selling processes. As we can only assign one sales process to one record type, we will need to create 3! In addition to this, they also would like to capture different data for each sales process, this will require 3 page layouts, in addition, to be assigned to each record type.

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 3 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 3 page layouts. The fact that we actually have 3 different profiles conveniently setup, means 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 automatically change record types based on escalation!).

11 thoughts on “When to use Record Types Vs Page Layouts?

  1. Avatar

    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. Ben McCarthy

      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. Avatar

    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. Avatar

    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?

Leave a Reply