Salesforce Change Sets for System Administrators

Here is an overview of the functionality and a few reasons why you should care about it as a System Administrator.

What is a Change Set?

A Change Set is a series of components that get deployed from one Salesforce environment to another. Typically you would use a Change Set to deploy work from a sandbox to production after the work has been thoroughly tested and approved. You can also deploy components in different directions such as sandbox 1 to sandbox 2. Or even from production to a sandbox. The org where you create your Change set is where you would create an “Outbound Change Set” and the org where it is being deployed to would receive an “Inbound Change Set”. This is all done through the power of Deployment Connections.

Understanding Deployment Connections

A Deployment Connection is the direction definition between orgs, allowing one Salesforce org to deploy to another Salesforce org. When you go to your setup inside of a production Salesforce org you will see the Deployment Connections link under the Deploy menu. Any sandbox created from the production instance will be listed there and will initially have a red broken linkage image. You can edit the Deployment Connection and allow for Inbound Change Sets and from there on in you will be able to deploy from that sandbox into production. You will notice a green arrow now replacing the red broken linkage image that denotes that you can deploy from the sandbox into production. You can do the same process in the sandbox and allow for inbound Change Sets from production in which case the green arrow image will now be pointing in both directions meaning you can deploy from production to sandbox and visa versa.

Adding Components to Change Sets

Once your Deployment Connections are setup it is time to actually deploy functionality. Functionality can be as simple as a newly revamped page layout for your Contact object to something as complex as a series of Apex Classes and Visualforce pages. The list of items you can deploy is rather large and wide-ranging. It doesn’t include every single thing you can possibly build in a sandbox but it covers most things that you would need as an admin to deploy tested changes. To add components to your Change Set first you need to create a Change Set.

A good practice is to give your Change Sets descriptive names and a version number - something like “Contact Page Layout Change v1”. Once you’ve created your Change Set you will land on the detail page for it where you can click the Add button within the Components section. From here you will use the Component Type dropdown to select the type of component you will be adding. In this case we would be adding a Page Layout and possibly and fields that we’ve created that we have added to our Page Layout. Select each item by using the checkbox next to the item and then click on the “Add To Change Set” button. You can then continue to add different Component Types until your set of changes is complete.

Uploading Change Sets

Once you have added all of your components it is time to upload the Change Set to its destination org, in this case, Production. From the Change Set Detail click on the Upload button and then select its destination. It could take up to 30 minutes to upload but typically it takes far less time than that, sometimes under a minute. Go ahead and login to the destination org and click on “Inbound Change Sets” in the setup menu and you should see your Change Set that you just uploaded. Click on it and then to Deploy just click on the Deploy button. You can monitor the deployment from the link on the screen and watch as everything gets loaded into your production org.

 Gotchas

A few things that can trip you up as you start using Change Sets to deploy functionality:

• If production and sandbox are not exactly the same, occasionally there will be dependencies in one of the components you are deploying that does not exist inside production - this is a good reason to always do work in your sandbox and then deploy it to production no matter how small the task.
• Make sure to include Profile Settings in your Change Sets - yet another reason to keep your environments as close to mirroring each other as possible. If you create a field in your sandbox and give field level access to users with a specific profile that security setting won’t deploy unless you include the Profiles in your Change Set. 
• Remember the small things such as page layouts, tabs, list views, and folders. These items often get overlooked when doing a deployment but since you’ve spent the time building out the functionality in sandbox you should make your life easy and deploy it all to production, no need to recreate any work.

There are lots of Ideas on the IdeaExchange for how to make Change Sets even better, here are some of my favorites:

Don't show Inbound Change Set link unless actually available 
Clone Inbound Change Sets

Please feel free to comment below, on our Facebook page, on the Salesforce Success Community, or directly at me on Twitter @JustEdelstein.