Have Record Types Become Obsolete? Rethinking the Traditional Salesforce Design Tropes for Record Types

New Lightning features are
changing the game.

As a two-time Lightning Champion, my main responsibilities are to evangelize the Lightning platform and assist the community by sharing my expertise and passion. These responsibilities have reinforced the need to stay on top of each new release and understand the creative solutions that the community has developed. Each new release changes the rules of the game and allows architects to stretch the boundaries of the platform.

This creativity also forces us to reconsider traditional design tropes that were once best practices and standard industry methodology. I want to dive deep into one such feature that I’ve been discussing a lot recently by posing a question:

Have record types become obsolete?

Lets start by reviewing the traditional uses of record types:

  • Controlling the page layout for users, i.e. different fields and related lists on a page based on business rules
  • Simplifying picklist values
  • Defining different business processes on an object
  • Managing user access for creating records of varying types
  • Securing record visibility within Sharing Settings

One of the beauties of Salesforce is that there is usually more than one way to build functionality. This has become more prevalent with the expansion of Lightning components and increased click-based functionality.

These features have increased the complexity of solutions and they are now forcing architects, product owners, and business leaders to more clearly define their strategic roadmap to secure a successful design.

One example is the combination of the Lightning Page, the standard components, conditional visibility, and dynamics forms. This subset of features enable admins to greatly increase their ability to build creative solutions by customizing the fields on the page, displaying fields from related records, and conditionally display or hide any of the above. This subset of features also completely eliminates the first bullet point above (controlling the page layout for users) for requiring the usage of Record Types.

The previous design trope around Record Types was to use them in conjunction with Workflow Rules and/or Process Builder to make intelligent changes based on record attributes. We now have the ability to do so much more without using any automation based tools!

These features have increased the complexity of solutions and they are now forcing architects, product owners, and business leaders to more clearly define their strategic roadmap to secure a successful design.

Granted, two things in that list (simplifying picklist values and defining business processes) still absolutely require a Record Type to work properly so we know they aren’t going away entirely… yet. This change in the functionality landscape makes you wonder about the other updates coming down the pike that will force best practices to be re-evaluated.