Salesforce Record Types are an incredibly powerful, and easy to implement Salesforce feature. With power and ease of build, comes a very high possibility of misuse. As Uncle Ben says: “with great power, comes great responsibility.” This is a feature that consultants and experienced Admins very often find is one that has been implemented incorrectly, caused poor data quality, and user confusion, which is the last thing you want in your Salesforce org!
Let’s start at the beginning…
What are Salesforce Record Types?
Record Types are a way of grouping many records for one type for that object, because these records have a lot in common. Record Types allow you to have a different page layout, with different fields, required or not, and with different picklist values. They can be applied to any standard or custom object in Salesforce.
When to Use Record Types
I’ll give you a few different examples of when Salesforce Record Types might be used, and why they are great in each scenario:
Hosted Event, Email Campaign, Tradeshow
Why Record Types are great: Each of these three things definitely meet the criteria of needing a “campaign” record, because they are very different in delivery. For Hosted Event and Tradeshow, I might need a lot of information around the cost of the event, location, etc. For an Email Campaign, there’s probably very little to no cost involved, and no location required, so those fields would be irrelevant (annoying if the user was forced to fill them out).
Custom Recruitment Object
A recruiting company has one custom object for “Open Positions”, but the fields you need to fill out for an entry-level position are different from an executive-level position.
Why Record Types are great: Again, all these records are the same, but have different expectations of what fields would be filled out.
The types of Cases a customer might need help with could perhaps be “Bug” or “Product Question” With a Bug, I might need steps to reproduce the bug, or ask for screenshots. With a Product Question, I only need to know which Product, and what the question is.
Why Record Types are great: Record Types on the Case Object allow you (and the customer, if you share this information through a Community) to only see the relevant fields, and not be bogged down by unnecessary clutter on the page layout. And since they’re both a single object, you can still report on your SLA’s in one place.
When Not to Use Record Types
So the reason to use Record Types is nearly always the same. Because they make life easier for the end-user, showing them what they need, and none of the stuff they don’t. They tell the user what is required for that Type, without bothering them with fields that are irrelevant. But most importantly, you need to also understand when not to use Record Types.
Accounts is an object I have seen many times with Record Types that had absolutely nothing different about them. It seems like a good idea, a “Customer” Account record seems like it would be vastly different from a “Partner” Account, which again, seems pretty different from a “Vendor” Account. However, when you actually sit down and look at the required fields for each, we find, there’s only a few, and they’re mostly the same.
For an Account, we might need to know:
- HQ Address
- HQ Phone Number
- Type (Customer, Partner, Vendor)
- Start Date (the date they became a Customer, Partner, or Vendor)
Most of what we need to know about a given Account is handled on its child objects (Contacts, Opportunities, Contracts, Assets/Subscriptions, etc.) so really there is almost no difference at the Account object level!
I see this same pattern on Contacts as well, but there’s even less difference there. For Contacts we generally need to know Name, Email, Phone, Job Title, Role, and perhaps Address. Does it matter that the person is a Vendor, Partner, or Customer? Not really – you most likely need the same information no matter what type of person they are.
6 Questions to Ask When Planning Record Types
When you’re looking at an object, and trying to decide if Record Types are necessary, think about the following questions:
- What object are we discussing?
- What are the types that might need different record types?
- How is each type different?
- What fields are required or needed on the page layout for each?
- What picklists might need to have different values (but still use the same picklist)?
- Do I need to run reports on these objects together most of the time?
Here’s an example of two Opportunity Record Types: New Business, and Annual Renewal:
They might look mostly the same, but actually, there’s several differences. There are different required fields: new Business requires Lead Source and Primary Campaign; however, Annual Renewal, doesn’t require those because the customer is already that (a customer). Instead, an Annual Renewal requires the Prior Contract number. And you may notice, that while on New Business Amount is not required, it is required on the Annual Renewal. Next Step is required on the New Business, but optional on the Annual Renewal.
Summary: Get Started Today
Depending on your learning and organizational style, you may want to do your decision making on a whiteboard, or in excel. You also may need to sit down and do a working session with your end-users; remember, you might be the expert Salesforce Administrator, but they are the experts in their day-to-day work, only they know what they need and what will be useful. And, no offence to the managers out there, end-users are often a better resource for day-to-day work than managers!
After you’ve talked to the end-users, then talk to the manager and find out their vision for how things should be, or what they imagine a great and easy user experience would be. Using both perspectives, plus your own Salesforce skills, you will be able to implement Record Types in the most effective way possible. And as always, create and test in Sandbox first, and have your end-users try out the new Record Types in the Sandbox before deploying to Production.