o you’ve got a new type for an object in Salesforce. Should it be a Record Type? Or will a Picklist suffice?
Creating new Record Types can cause you all kinds of trouble down the road. We've listed everything you should consider when thinking about potentially adding new Record Types, best practices for when to use this feature, and tips for when you should be able to get by with just a Picklist.
First Principles: When in doubt, don’t use Record Types.
If you’re waffling, it’s a hard no. Record types are dangerous. Using them will bring you all kinds of pain:
- More steps and clicks for end users and admins
- Prevents Inline editing in list views
- Creates hassle when creating new picklists and picklist values (particularly if you push from sandbox without profiles - I’ve lived this nightmare before)
- Page assignment rules to set/maintain for each Record Type. When I add a field, I now have to place it on all of my page layouts.
- Users may not understand Record Types for Reporting
- Each Record Type requires setting up a different “Process” (for stage/status Paths)
- Creating new records now requires a type - via API, action, anywhere
- All sorts of other gotchas
These may seem minor, but trust me, Record Types are a pain, especially when you have lots of them and a picklist does the trick. Should you avoid them altogether?
When to Make a New Record Type
1. When The Difference is Obvious to Everyone
The first rule of thumb of Record Types is to use them when you have two very different things; a line that is obvious and distinct to all users of your org. For example, Customer vs Partner Accounts, New Business vs Renewal Opportunities, etc.
2. When You Definitely Need Separate Pages, Buttons, and Picklist options
This one is sortof redundant to point 1, because if 2 is true, 1 is almost always true. Said more simply, if it is obvious to users that Customer Accounts are different than Partner Accounts, then these things should look different. However, make sure they should look meaningfully different: write a list of all the things that would be different when looking at each type of record’s page. If there are more than a handful of items, that’s your cue.
3. When Completely Different Teams Own Each Type
Sometimes, you have one team working with one type of an object, and another working with another. This situation becomes dangerous, because you don’t want one team’s items creeping into another’s list and accidentally getting edited. Team Collisions can really sink user adoption, because users hate entering information just to have it get messed with, overwritten or deleted. A great reason to use Record Types to is to prevent these sorts of cross-team collisions. You can make it required to pick which team this record belongs to; as well as obvious which kind it is when you land on one. Remember, you can set a default Record Type for each Profile, and you can make it so Profiles cannot create (but can see) certain Record Types.
Summary
All in all, you should use Record Types judiciously, but when appropriate. You’ll find your instance is easier to maintain, with a higher quality of life for end users, and everyone will be happier. Still in doubt? Drop us a chat on the situation you’re currently considering Record Types for, and we’ll weigh in!
