Traditionally, record types drove all of our UI-related decisions in Salesforce. In Salesforce Classic, record types drove page layouts, which data was visible on the page, and many other decisions, including picklist values, processes, and more.
But now, in the Lightning World, record types have begun to lose a bit of their meaning and functionality, but still have a big role. Picklists, default profile assignments, and processes and paths still play a big role in determining when to use record types in Salesforce, especially for sales processes and paths since these are often driven by picklist values. We can see this with cases from the customer service side as well.
But now that we have Dynamic Forms, we have a lot less reason to to use record types for User Interface-related changes when you can control a Lightning Page for multiple personas. Now the days of 25 page layouts and 15 record types are over!
So with the introduction and steady onboarding of Dynamic Forms as a way of customizing Lightning Pages for different personas, how should record types be used now? Should we continue to use them to customize pages? Or should we begin to limit their use cases?
When to Use Record Types in Salesforce (Other than for the UI)
We know that record types are typically used when you have different personas that need to work on a record, but will have different data access and layout needs. But when else are you supposed to use record types in Salesforce?
Picklists are going to be a big one. If you need to manage picklists for different sets of users, record types are necessary to fulfill that requirement.
In addition, there are several other components that are driven by picklist values, and therefore would be record type dependent. This would include default profile assignments, paths, sales processes, case processes, solution statuses, and lead statuses. Again, these are not record type controlled, but the processes behind them are. Because those processes must be assigned to a record type, you don’t control it with a record type.
Another big application of record types is with Person Accounts. Person Account record typing is still very much required in order to differentiate them from traditional account records.
Salesforce (and the ways we use it) are Constantly Changing.
Salesforce has shifted so much in 2 years, and so much has been consolidated in Lightning. That being said, how we use record types is changing.
Historically, permission sets were as hard to manage as profiles. Profiles historically controlled record types and therefore page layouts and UI. Now, a lot of that has been opened up in flexibility such that you can get to that one Lightning page with dynamic components. You can have different sections based on different business units rather than different page layouts as a whole. Additionally, Salesforce recommends not having more than 200 record types in an org – so ensuring that you don’t hit this number, especially when it’s no longer necessary, is valuable in keeping your org maintainable.
Dynamic Forms are Coming.
At the time of this post, custom objects, Accounts, Contacts, and Opportunities are supported by Dynamic Forms. And very soon, in Spring ‘23, Leads and Cases will be supported soon.
Dynamic Forms are not currently supported on Salesforce Mobile, but this will be available in pilot for Spring ‘23. Additionally, since newer iPads can support Salesforce Desktop, those devices are currently able to access the Desktop version of Salesforce.
So while Dynamic Forms isn’t 100% supported at the time of writing this post, we are getting closer and closer to that point. And as we near that point, we can actually get started with condensing our page layouts and switching to Dynamic Forms.
How do you know if the object you’re working on is currently supported by Dynamic Forms? In addition to checking the documentation, while you’re on the record page of the object you’re working with, click the Setup Cog in the top-right corner of the page and select ‘Edit Page.’ In the top right of the Lightning Page Editor, a Dynamic Forms information dialog box will appear if that object supports Dynamic Forms.
When selecting the record detail on the Lightning App Builder Page editor, if you see the info dialog and the ‘Upgrade Now’ button, then this object currently supports Dynamic Forms!
So, When Should You Actually Use Record Types in Salesforce?
With the introduction of Dynamic Forms, we have less of a reason to use record types and page layouts when there’s an easier way out there to maintain them. Additionally, the list of limitations on the record type article diminished drastically, even from a considerations standpoint.
So what do we recommend? Start reducing the number of record types per object. If it’s not there for reasons described above, such as picklist values, person accounts, or something driven by picklists, such as processes, get rid of it! Dynamic forms will take the place of multiple page layouts and therefore multiple record types to produce a much better result. This gives more flexibility and freedom for admins to build better Lightning Record Pages that are maintainable, rather than have to maintain multiple layouts.
With any new org that you implement, create a bare minimum number of record types. Use custom permissions assigned to a permission set to define filter criteria on one Lightning Page instead of multiple record types to determine multiple page layouts. This will ultimately prevent overcomplicating maintenance – after all, multiple record types are not fun to maintain!
Where We’re at vs. Where We’re Going
Record types have always been a UI/UX consideration than anything else, and with the expansion of lightning features and modernizing this old functionality, we would not be surprised if record types began to phase out – it seems like that’s the direction things are going. That being said, reducing overhead and maintenance and considering adopting dynamic forms and handling all of the UI/UX needs within the Lightning Record Page itself rather than the older features will be beneficial to reducing overhead. It wouldn’t be anytime soon, but it is a worthwhile endeavor to begin phasing out record types in favor of Lightning App pages to consolidate your efforts.
Tim Wiech
Solution Architect
As a Salesforce Solutions Architect, Tim has spent the last 7 years building and scaling the Salesforce.com platform for companies of all sizes across a broad scope of industry. A rich background in business process automation and IT solutioning has given him a wealth of knowledge for cloud technologies within and connected to the Salesforce ecosystem. At Roycon, he brings that knowledge and approach to scale to the delivery of our clients vision.
About Roycon
We’re an Austin-based Salesforce Consulting Partner, with a passion and belief that the Salesforce platform’s capabilities can help businesses run more efficiently and effectively. Whether you are just getting started with Salesforce or looking to realize its full potential, Roycon specializes in Salesforce Implementations, Salesforce Ongoing Support, and Salesforce Integrations, and Development. We’re the certified partner to guide the way to increase Salesforce Adoption, make strategic decisions, and build your Salesforce Roadmap for success.