Why Salesforce Record Types?

Salesforce Record Types have been around for ages, with countless articles, videos, and tutorials explaining what they are and how to use them. Instead of rehashing the basics on what a record type is or how to use them, this post will dive into the "why" behind record types, with considerations drawn from my experience working at Salesforce in Org62, one of the oldest and most complex implementations of the Salesforce platform. Despite the evolution of Salesforce technology and business processes, record types have stood the test of time, remaining a vital tool for tailoring Salesforce to meet business needs.

To explain what a Salesforce record type is and how to use it, look no further than this 5 minute video and article from Salesforce Help & Support that explains what are record types. This is how I would explain record types to someone learning for the first time. I like it because while record types are commonly associated with controlling fields, page layouts, and picklist values, what is often overlooked or not emphasized is how they enable different business processes, and in the video, they use a classic example of internal vs external case management to explain why record types are the perfect solution to distinguish one process from the other.

A deeper dive...

When configuring record types, yes we're adding fields for one page layout and removing fields for another page layout, and yes we're changing picklist values to meet our needs, but if we take a step back and look at the bigger picture, all these smaller changes are part of a bigger plan to facilitate different business processes. In the example of internal vs external cases, one is a case management processed designed for your external customers to submit requests when they need support, while the other is a case management process designed for your internal employees when they need support for things like software & hardware installation, or access to data. Case management is the solution that underpins both groups, but while customers focus on providing issue details, inquiries, and other support requests which are not applicable for the internal employee, the internal employee might need to specify laptop and software app details which would not be applicable to the end customers. This plays perfectly into a record type's ability to control page layouts and fields, but once a request is submitted and a case is created, the process to resolve the case will vary significantly.

Case Process - It's very likely both external and internal support processes will start with a status of New, followed by a status of In Progress, and end with a status of Closed. No argument there. But for customers, I want a Resolved status which communicates to the customer - the issue reported has been resolved by the support team; please take a look and confirm. This status is important to my process because I don't want to close the case without receiving confirmation from the customer and I don't want to leave the status as In Progress because it would lead to confusion (as a customer is it OK for me to review the fix or is the support team still working on the issue?). And because I want to track key metrics and KPIs like average time to close a case, I don't want cases to be closed pre-maturely if the customer reports that an issue is not resolved on their end. For internal employees, I won't be using the Resolved status, but because approvals are mandatory for most software & hardware requests, I want Pending Approval, Approved, and Rejected statuses as part of my internal support process. These statuses will pair nicely with the approval process I plan to setup and they will communicate meaningful updates as an internal support case travels through an approval process. At this point, it's early but I know I have two distinct support processes with different picklist values in my case status field, and different page layouts to gather different inputs. And based on my discussions with the internal and external support teams, there's a vision and roadmap of capabilities they want to incorporate in the future for their respective processes. I'm confident we need to create record types. I first head to Object Manager to add the picklist values to the status field on the case object, create new fields as needed, and create separate page layouts. Then I navigate to Support Settings to create my internal and external support processes and assign the respective case status picklist values. Finally I navigate back to the case object to create my internal and external record types using the respective support process I recently created, assign page layouts, and of course make profile changes for record type access. From a maintenance perspective, I'm already looking ahead and thinking because I've decoupled my internal and external support processes with separate record types, page layouts, etc, I know that I can make relatively safe changes to one process without impacting the other. If we didn't use record types to separate our processes, how disastrous would it be if we make changes to optimize the internal support process and break something in the external process preventing external customers from getting the support they need?

For smaller organizations that may have not seen this yet, imagine you have two small but mighty teams supporting internal and external support cases respectively, and everyone uses the same page layout and case status values. To avoid additional maintenance effort, the direction is to share the same page layout and reuse processes. This path quickly falls apart because what happens, even in small organizations, is that the team providing external case support will want changes to the page layout that the internal team doesn't need and vice-versa the internal team wants changes the external team doesn't need. Fields, workflow automations, validation rules, and support process for both the internal and external teams all blend into one page. No one is happy and everyone is confused. Customers are frustrated that it takes a long time to get help and are seeing parts of the internal process leak into their support cases. With record types, it's easy to segment distinct business processes and maintain them separately while still reaping the benefits of common functionality.

Lead & Opportunity Processes - In the internal vs external case support process the case object is the star of the show, but out-the-box Salesforce has 2 other objects that are heavy on process. One is the lead object, where we can setup different lead processes for qualification and conversion of leads. The other is the opportunity object, where we can setup sales processes to cover different sales motions - new business, add-on, renewal, professional services, and more. It's by design that Salesforce allows customers to configure a process for each of these objects and it's by design that case status, lead status, and opportunity stage are picklist fields that can't be modified in a record type like other picklist fields. As part of the record type creation process, I must assign a support process, lead process, or sales process to drive the picklist values for the respective case status, lead status, and opportunity stage picklist fields. It's important that I create this process (or reuse an existing one) with much intention and purpose. The potential for misuse of record types comes if my only objective is to create a new record type because I know I can use it to assign a different page layout. I may end up reusing an existing process and hitching my wagon to some other business process that could change in the future and negatively impact my solution. Or I may unnecessarily create a new process which mimics an existing process and now there's additional overhead in maintaining the system. Were there other options? Could I have avoided a new record type? Continue reading for alternative options.

Custom Objects - It's possible to enable record types for a custom object, and most of the steps and benefits are the same, but a key difference is that Salesforce does not have an out-the-box setup feature to create/maintain processes for custom objects. If one or more processes do exist for a custom object, a status field or something similar would be key to facilitating that process. Because there is no process to create, the admin would go directly into the record types for the custom object and adjust the picklist values in the status field.

RevOps - Sales operations support is another good example of internal case management. At Salesforce the RevOps team needed a solution to provide sales ops support to our sales and customer-facing teams and we determined based on their need that the Case object and case management was a perfect fit, but their processes for handling support requests are different from external customer requests and other internal case management processes. The processes used by the RevOps organization and the information gathered for each sales ops support request varies significantly. Quote support, questions about commissions, or questions about account and territory assignment are very common. In a very large organization with thousands of sales people and limited RevOps support resources, effective case management is a must. And because other case management processes already existed, it was clear that a new record type, new fields, new page layouts, a new process, and workflow automations were needed to meet business needs while not impacting or disrupting existing support processes.

What a record type isn't...

• The name is misleading - When we hear "record type", a common misconception is to think of record types as a way to categorize records of an object into different types, hence the name. At the end of the day we do end up with different types of records but that's not why we use record types. As an example, if all I needed was to track different types of cars for a car rental company, for example sedan or SUV or truck or van, but the process for renting a car doesn't change from one type to the next, then I don't need record types. I just need a simple picklist field on my car object to track type.

• It's not always necessary to create a new record type to assign a different page layout - Page layout assignment is based on profile so if a group of users need to see a different page layout and they all are assigned to a profile different from the rest of the user base, then all we need is to create a new page layout, add the fields/sections/buttons/etc as needed, and assign the page layout to the profile for those users. As an example, if the customer support team shares the account page layout with the sales team but realize one day that they could be much more efficient supporting customers if they could add key support related information on the account page layout then, assuming the customer support team has a different profile assignment from sales, all we need is a new page layout along with a page layout assignment to the customer support profile. No new record type required.

  

• Explore other options to control fields on a page layout - What if I'm an admin and my business team says their users are all on one profile but some of the users need to see a field on the UI and the remaining users on the team don't need to see the field. We are told the guidance is to not create new profiles because a lot of profile specific logic already exists. I need a new record type right? Well not so fast. If it's just one or a few fields that we're talking about, then maybe we can set Field Visibility criteria and hide the field under certain conditions for users that share a specific role. Or maybe there are no filter conditions to make Field Visibility work. We could update the profile to make the field hidden for all users then use a permission set to make the field visible for certain users. THE KEY is hidden in the detailed conversations with the business stakeholders and end users. When the discussion includes explanations that hint at variations in process, it's very likely the business team has different business processes that they're maintaining and you just have to sniff it out. The key word you want to listen for or read is "process" or a similar word like "scenario". If based on conversations you have picked up on more than one process and there's a variation in fields or data collected or a variation in picklist values like different status values, then bingo, there's a good chance we need a new record type. But while we may have found our potential solution, it's important to weigh options before creating a new record type because there are hidden implementation and maintenance costs down the road to consider when using record types.

Key Considerations

• For starters, here's a Salesforce help article that lists considerations. It's a good list but not exhaustive so learning from different sources on the internet, like this article from Salesforce Ben, is a good way to round out your knowledge. For example, one consideration I did not see in the Salesforce help article but learned from others is that if record types are enabled for an object with pre-existing records, those records must be revisited with a tool like Data Loader to update the record type. Or if you're on a list view for an object that uses record types, you can't inline edit and bulk update records in the list view unless you first apply a filter on record type. This restriction exists because in any given list view, a user can see records across different record types but the user's profile controls whether or not the user can create or edit records for that record type. In a scenario where a user sees records in a list view with a mix of record types, some that the user can access and others that the user cannot access based on their profile, inline edit would fail because the user should not be allowed to edit records which the assigned profile does not allow. (I'm using words such as "see" and "access" which can lead to confusion - if the user can "see" the records what do I mean by they can't "access" the records? By "access" I mean the user cannot edit or create records for a particular record type). Why can't they edit records of a record type they don't have access to? One reason is that the record type can have a picklist field with specific picklist values. If the record is in edit mode, the user won't be able to select from all picklist values for the picklist field because the user is not permitted to use that record type. Salesforce restricts the user from editing the record because the user cannot properly edit the record without complete access to all picklist values. The other reason is page layouts. The user may be viewing the record with a page layout that does not apply to the record type of the record. If the user is not viewing the appropriate page layout for the record type of the record, then there's a chance the user is not seeing all the fields meant to be seen with the page layout for that record type and cannot properly update all the applicable fields.

• Record Types in Automation - another major consideration in my experience is something that others have touched on but I'll expand. Earlier I mentioned that a lot of my experience comes from working in Org62. It is a very complex org which continues to carry legacy business logic, configurations, workflows, and code from the early beginnings of Salesforce. Record types were in use from a long time back but as business needs evolved over time, new product features released or enhanced, and business processes of acquired companies were integrated into Org62, record types became harder to use and maintain. There were so much record type specific business logic in workflows, process builder, flows, Apex code, assignment rules, sharing rules, and other configurations that for big and small changes we had to revisit a lot of areas and make adjustments to include (or exclude) records by record type. Even with all the due diligence, something would get overlooked and issues would crop up. If not careful, other teams could be impacted because record types were not handled properly, leading to escalations and late night production support calls. For example we had assignment rules that worked really well when it was just the customer support team, but as more case record types were created to support internal case management processes, we had to include record type logic in the case assignment rules to make sure cases were getting assigned to the correct queues/teams. As another example, there was a validation rule that triggered when the opportunity reached a certain stage.The rule required the sales team to enter competitor information before moving on to the next stage. Without checking record types, the validation rule would require competitor information on renewal opportunities which did not make sense for renewals. Once record types are incorporated into the solution, it's almost inevitable that they find their way into workflows, validation rules, flows, Apex, etc and it becomes very important to design solutions with record types in mind.

• Training & Education - It's easy to think that the job is done after all the record types, page layouts, fields, profile changes, etc are configured but what inevitably happens is users will see an option to select a record type when creating new records, or they'll see the Record Type field on the page layout and wonder why it's there and what's the correct value to select. It's important that record types are explained in detail so that users know how to use them properly not just the first time but every time, even as new users are onboarded into the system. And if record type related changes are needed in the future, it's important the relevant business stakeholders are aware of how record types are associated to different business processes so that they can make informed requests for changes. Imagine a non-technical business stakeholder requesting for a change and the admin asking what record types are applicable to the requested change. The discussion can quickly fall apart and the wrong changes applied to the system if record types are not properly explained. The reality is different business process owners should be engaged to discuss and determine if the new changes are something they want to apply to their business process and associated record types, but more often than not, time can be a limiting factor. The next best thing is to limit the change to the record type known to be applicable and wait for the business to come back with further instructions. It's not ideal but in very large organizations, managing record types and numerous business processes can be very challenging. A business process architect would be a good role to fill when there are numerous complex and overlapping business process to manage and maintain.

Final Thoughts

Record types are indispensable for large organizations with complex needs, but they should be approached thoughtfully. While it's true that record types help us control fields, page layouts, and picklist values, always start with the business process in mind and ask what business process will this record type represent if I create it. If there’s no distinct process, explore alternatives to achieve business needs. Proper planning and communication with stakeholders will save time and headaches down the road.

Ultimately, record types are not just a technical tool—they're a business process enabler. By understanding their purpose and limitations, you can harness their full potential to optimize your Salesforce implementation.

Have you faced similar challenges or discovered unique uses for Record Types in your Salesforce journey? Share your experiences in the comments below—I’d love to hear how you’ve navigated these complexities!