How to Deploy Salesforce Record Types Correctly
Salesforce Record Types should be used for records that have the same concept, but the execution and processes of each are be different. When used correctly, you can improve data quality, reduce manual effort and streamline processes. If you’ve read any other of my blog posts, you know I’m a big fan of Record Types!
There are Record Type best practices that Admins need to make before even touching Salesforce to ensure you have a plan prepared and a clear understanding of how each Record Type will be different. It goes without saying, but your initial build should be in a Sandbox. Once you have built and tested, it’s time to deploy your Record Type to your production environment – which can be straightforward if it’s a new object, but with additional considerations for an object already in use. Here are the steps you should follow to correctly deploy Salesforce Record Types.
Setting the Scene: Get a Move On!
No, that’s not me trying to hurry you along. That’s just the name of my fictional company Get a Move On! Get a Move On! manufactures custom boats, cars, motorcycles, and small airplanes. We’ll use a custom object in their Salesforce org called “Vehicles”.
These are the record types they have created:
Step 1: Outbound Change Set
After you’ve created the Record Types, add them to your Outbound Change Set. Just go to your Change Set you created earlier, and click “Add”. Record Types can be found under Component Type → Record Type. Just check the boxes next to the ones you need, and then click “Add to Change Set”
Step 2: Create Custom Fields
Next, you’ll want to create any custom fields in the sandbox you might want for each Record Type. Check out this blog post for tips on planning custom fields for Record Types.
A special note about picklists and Record Types!
Picklist fields can be further customized to have only certain values available on a picklist. In this example, my Record Types are a few different types of Vehicles. Each vehicle only has only certain seating options, but we don’t want to make a special “Seats” picklist for each Record Type. All we need to do is select the Record Type in question, and then customize a single “Seats” picklist with the only selectable options for that Record Type.
Here’s the Seats picklist for all my company vehicles together:
|Airplane||4. 6, 10||6|
In the Record Types section, you’ll need to click on the name of each Record Type, select the picklist you want to modify, and then choose the available options and the default value.
Step 3: Page Layouts and Lightning Record Pages
Once all your fields are ready, you can start working on your Page Layouts and Lightning Record Pages. Make sure to add them to your Change Set when you’re finished.
Step 4: User Profiles
You’ll also want to add any profiles to your Change Set, as needed:
When you include your Profiles in your Change Set, your picklist dependencies should come over to production along with everything else. But, if they do not, or if you do not want to include Profiles in your Change Set, you can always set your picklist dependencies again once it’s deployed to production. (I always treat the sandbox just like I would treat the production org, so I set visibility for Record Types, fields, etc, as if I were in production.)
Step 5: User Testing
Now is a great time to have your end users do some Sandbox testing – make sure the Record Types work the way they expect and make any additions or further customizations.
Once your testing is completed, you should create some training documentation for your end users, and notify them about when you will be going live. You will want to explain the purpose of Record Types, and how they are used in your org. I recommend a training video and a PDF guide, in addition to a live training. Every person’s learning style is different, and providing a variety of training formats allows the user to choose the one that works best for them.
Step 6: Deploy!
Now you’re ready to deploy your Record Types to production! This can take a little while, so take lunch break or go for a walk while you’re waiting. You will get an email when this completes.
Once the change set is in Production, you can validate and deploy it.
Things you will need to do once the record type is in production:
- Do a more testing to make sure that everything functions properly
- Is visible and ready for your end users.
Step 7: Existing Records
If you add Record Types to an object that already has records, you’ll have some extra homework to do.
You’ll need to do some cleanup of your existing records to make sure the picklist values align with the intended Record Type (if you’ve customized them), and then you can use something like Workbench or the DataLoader to update all existing records to the proper Record Type.
In this example, let’s say this was an existing object (Vehicles) with only a picklist to determine if it’s a Car, Boat, Airplane, or Motorcycle. So my old plain picklist exists, and 599 existing Vehicle records exist. You’ll need to run a report of all existing Records, and just include the ID column, and the old picklist. (In some scenarios, you may need more than one field to determine what the new Record Type should be.)
Next, you’ll need to get the new ID of each Record Type you created. You can get the ID from the URL string (it’s a bit more obvious in Classic)
and add it on to your CSV in a new column. Make sure to remove any columns that are unnecessary. Remember, at this point, all you’re trying to do is to update existing records with a new Record Type, so you only the the ID of the existing Record, and the ID of the new Record Type.
Import using your favorite import tool: the Salesforce Wizard, DataLoader, Workbench, etc. Once your import is complete, you should be able to see in Salesforce all the existing Records now have the proper Record Type.
If you no longer need that original picklist, this is a good time to follow whatever your org’s policy is for removing old fields.
Record Types aren’t especially difficult to create or implement, but it’s easy to make mistakes, or implement them when they aren’t really needed in the first place! As long as you plan carefully and do thorough testing in the Sandbox, your users will be happy and your Record Types will have a long and happy future!
All that cleanup would be SO much easier with Apsona, which lives inside Salesforce and doesn’t require all that spreadsheet manipulation. DM me for a tour. They don’t pay me. They just took a thorn out of my paw when I was a child, so now I owe them.