Cart

Salesforce 102: You Probably Don’t Need So Many Record Types

Welcome to the Marketwake Salesforce 102 Series — an in-depth rundown on insights that can help even the most proficient Salesforce users do things better. Why? Because even the experts can use a refresher course from time to time. Here’s what we know about being the best to help you dominate your customer relationships.

You may think you know Salesforce, but what if I told you …

You may not need all of those record types and page layouts to display tailored content to your users.

One of the best features of Salesforce is that it affords admins the flexibility to display only the content an end user needs to see in order to do their job. Sure, the principle of least privilege plays a part here, but I also like to think that admins are goodhearted (and also uncommonly good looking) people who want to make spare users from endless page scrolling, overwhelming tabs, and confusing click paths. At the end of the day, we’re just here to make everyone’s life a little easier.

To that end, admins have typically used Salesforce to leverage custom/standard profiles to provide access to specific apps, objects, and fields. Some admins have even taken this customization a step further by using record types and page layouts to create custom user experiences.

Before Lightning Experience was released, it was very common to open up a client’s org and see lots of page layouts and then use record types to determine which page layout would be used to display the record. Now that Lightning is everyone’s new reality, things are a little different, with lots of opportunities to improve. But first, migration.

When transitioning a client from Classic to Lightning, there are a couple of recurring themes that surface as we try to determine which legacy page layouts we need in the new org, and which ones can get nixed:

“I actually don’t know why we have this, I think Steve created it for something. Steve hasn’t worked here since the turn of the century. Great guy, though. Actually, one time at the holiday party he….(queue embarrassing and entertaining story that makes me want to party with Steve)”

“We have this page layout because our AEs don’t need to see all of the related lists that our sales operations team does. So, we created a page layout with all of the related lists and one with just some of the related lists.”

Lightning Experience may not be able to help out with the strange dynamic that plays out when you mix co-workers, alcohol, and holiday cheer. However, it can certainly cut down on multiple page layouts used to display certain related lists or components.

If you haven’t already met, I would like to introduce you to Dynamic Lightning Pages. Dynamic Lightning Pages allow admins to use one-page layout and one lightning page, but set varying component visibility based on standard field data, advanced field data, and even global object data (like user information).

For example, let’s go back to our related list situation: Let’s say your sales ops team needs to see the “Projects” related list when they look at an Opportunity record, but your AEs don’t want or don’t need to see that list.

Here is how I would go about this:

Navigate to the correct lightning record page and click “edit”. This will launch the lightning record page editor.

Now go to the left of the edit screen under the standard lightning components section and grab a single “Related List – Single” from the component options. We are using this component because I only want to set visibility for one related list and not all of them.

I would then drag that “Related List – Single” component into the desired page section.

Next step would be to select “Projects” from the “Related List” dropdown on the right side of the editor to indicate which related list I would like to render.

Now for the fun part: While I still have the Projects related list selected, I scroll down on the right side of the editor to the “Set Component Visibility” section and then click “+Add Filter”.

Before we get all visibility filter happy, let’s talk about how this works. If you do not add a filter, the user will see the related lists added to this lightning page layout as they normally would (provided their profile allows them to access the object, the related list is on the page layout, etc.). When we add a filter to the lightning page layout, we are essentially telling Salesforce: “Don’t let this component show up to users unless these filter criteria conditions are met”. Another way to think of this is that adding a filter locks down component visibility and adding filter criteria opens it back up.

Back to the example. After you have clicked the “+ Add Filter” button, select the “Advanced” filter type tab and then click the Select button under *Field.

A pop-up window will appear that allows you to select your criteria field. I would select User → Profile → Name.

From the next popup, I would use an “Equal” operator for an exact name match on the profile name and then type the profile name.

Then click “Done”.

Boom! Just like that the Project related list appears on the Opportunity record for members of the Sales Ops profile, but not for any other user profiles. No additional page layouts, Lightning pages or record types needed.

This is a simple use case, but imagine the possibilities when you combine all of the standard and custom lightning components available in the Lightning page editor. Not to mention that filtering can also be set based on related record fields, seven different operators, each component can have up to 10 filters added to it and so much more. I would honestly be surprised — and would never blame you — if you have already stopped reading this post, hopped into a dev org, and somehow lost hours of your day creating component filters.