Deep Diving Into Salesforce Record Types

I like to think of record types as “slices” of an object. You may have a standard or custom object with no record types which means each record within the object will be the same or you may have anywhere from one to hundreds of record types per object. While there aren’t any specific limits around how many record types you can have per object Salesforce.com recommends no more then 200 per object - now that’s some serious business process if you need 200 record types. Each record type represents a different process that you are managing

within the overall object. Lets use a simple example as we go through this entire blog post of a project object that is used to manage two distinct types of project - Internal and External projects.

Use Cases for Record Types

Here are some details around what makes up a record type at a high level. The most common use for record types is to create a different page layout for different records within the same object. Using our project example, for Internal projects you may want to track only a minimal number of fields and therefore would want a different page layout then you may want for an external project.

By having different record types you are logically splitting the different records, or processes, into different slices of the database. With this you can then assign a different page layout to each record type for each profile of user to see. In addition you can have a picklist called Status on the project. For internal projects you only need bare bones information like Open or Closed but for an external project you may need different statuses altogether; record types allow you to handle this with ease. Each record type has their own values available for a picklist on the object, this is really where the different business process comes into play and is really useful.

A practical place where the above is used is via workflow field updates or approval process field updates. As a step in a workflow you can flip the record type of a record therefore making available different fields on a page layout and different picklist values in the same field that weren’t available before the workflow happened. This is some fancy stuff and the best part is that it’s all declarative, no coding necessary.

Common Misconceptions

One of the major misconceptions around record types is how the security is handled on them. Record type selection is handled at the profile level (hopefully at the permission set level at some point), the key word in this sentence is “selection”. That is all that is really controlled at the profile level - the control over which record type a user can select when they are creating a new record. Each profile has a default record type for every object, if there are no record types defined then under the covers the record type assigned is called the “Master”, otherwise it’s explicitly defined on the profile level. Defaults are used in two places that matter (in my opinion).

The first is the “jump page” when you create a new record on an object that has more than one record type, the default will be the first in the list and be selected by default (go figure). The second is more intricate and I feel more cumbersome on administrators and end users trying to understand record types and that is during Lead Conversion.

Lead Conversion is a major business process flow in the Sales Cloud. When a user converts a Lead no matter what record type of Account, Contact, and potentially Opportunity they actually “want” to create they are going to end up creating the record type of their default on their profile. Most times this is fine but I wish there was a way to on the conversion screen define which record type I want to create because sometimes you may have a Lead that you want to convert to a “Partner” account and other times you may want to convert them to a “Client” account or “Prospect” account. While the above is a problem, like most problems in Salesforce.com there is a workaround. You can put a picklist on the Lead record and map that to a picklist on any of the records that you are creating and use the value of the picklist to fire a workflow to flip the record type upon conversion.

The last of the misconceptions is around visibility to records and how that interplays with record types. Records with specific record types are not hidden based on what a user’s profile says they have access to - remember those permissions are really for just saying what record types a user can create. With that said record types are a logical place to start when you do want to share or hide records based on criteria. In this case you would want to go to the org-wide default sharing settings and write some sharing rules that use record types as the criteria. This is a commonly used technique but often times it is confusing.

Consider the following use case: In our fictitious org where we have internal and external projects there is a profile where a user can create both internal and external record types of projects. In this same org the org-wide default setting for privacy for the project object is set to private and this user with permission to create an external project is actually by design prevented from seeing any projects with the record type of external. What would happen if this user then created a project with a record type of external as their profile allows them to? Quite the puzzle eh? Turns out the user would be able to create the record but as soon as it’s saved they would get an insufficient privileges message telling them they can’t see the record that they just created. Isn’t that just some fun stuff?

Oh Those Tricky Record Types

There are so many times where record types have tripped me up when trying to do something inside of Salesforce. Here are the two big ones that for some reason I have a hard time remembering to do.

Mass Edits from a list view - in order to actually mass edit records in a list view for an object that has at least one record type you must include a record type filter in the list view so that every record within the list has the same record type.

The other is more of a lapse in concentration as often times I will push Visualforce pages from a sandbox that references fields, particularly picklists, and in the Visualforce page there will be no values in production. This is because I sloppily forgot to push the record type along with the code and fields and therefore there were no values actually assigned to the record type in production. A good reminder to always test everything as soon as you push it to production.

All in all I feel like record types are a key in the area of managing business process within Salesforce.com. What do you think? Are there any other misconceptions, gotchas, or tricky/cool things that record types do for you? Tell us in the comments below, on our Facebook page, or tweet me directly @JustEdelstein.