When to use Record Types Vs Page Layouts?

Share this article...

When I first started out in Salesforce revising for my ADM201, questions like these were the bane of my life. Record Types Vs Page Layouts, Lookups Vs Master-detail, Workflow Rules Vs Apex Triggers, and the list goes on. But after conquering half a dozen exams and getting a few years experience under my belt, these types of questions turn into a breeze, and solutionizing becomes second nature. I find that the reason these questions become so easy, is due to the fact experienced professionals have 10’s of use cases they have worked on previously. With this not being possible at a more junior level, it becomes a lot harder to imagine a solution, but also the correct feature to use. Because of this, I thought it would be a great idea to put together some clear examples and explanations of common mixups and confusing features. First up, Page Layouts Vs Record Types…

Page Layouts

“Page layouts control the layout and organization of buttons, fields, s-controls, Visualforce, custom links, and related lists on object record pages. They also help determine which fields are visible, read only, and required. Use page layouts to customize the content of record pages for your users.” – Salesforce

Page layouts determine which data is displayed to your users on a record. As mentioned within the quote above, you can pretty much change any element from a page, removing fields, sections, links and custom Visualforce code. You can apply page layouts to groups of users (Sales, Support, Finance, Management), to only show data that is relevant for that group of users. But more importantly for this article, you can also apply page layouts to record types.

One important thing to note when using page layouts, is that you can only apply one to a group of users per object per record type. For examples if you have one record type on Accounts, 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. You might create record types to differentiate your regular sales deals from your professional services engagements, offering different picklist values for each.” – Salesforce

The quote taken directly from Salesforce’s help and training guide about record types is a great concise overview around the functionality surrounding them. Essentially when evaluating whether you need a separate record type, you will need to relate the business reason back to one of three things, you need different business processes (Lead Status, Opportunity Stage, Case Stage), you need to be able to show a subset of values from a Picklist field, or you would like a record or a group or users to see a different page layout. As mentioned above, if a certain profile needs to see 2 different page layouts on the same object, then 2 record types will need to be created.


A – Support users are being onboard onto Salesforce. They are required to view an extensive amount of information on Accounts around the customers technical solution. This information does not apply to any existing users. They have two Support profiles.

With this example we have quite a straight forward 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.

As mentioned above, 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 is 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 have a requirement to show different information on the page layout, depending 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 straight forward 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 type based on escalation!).


Page Layouts & Record Types are such a commonly used feature within Salesforce, it’s good to get a grasp on how to best utilize them. Learning the differences and where each one applies is a sure fire way to make sure that the systems you implement are fit for purpose.

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