Saving Time With Change Sets

There is nothing more maddening than to complete a configuration project, ensure that it is fine tuned and fully operational and then realizing that your creation still has to be moved to production. What a let down! The great thing is that Salesforce has a way to transfer all of that meta data into another org using a process called Change Sets.

They are an integral component to change management. Developing new functionality in a sandbox or dev or is 100% recommended – even for some smaller changes. Building and testing configuration in a sandbox ensures that your production environment isn’t compromised. While this may be happening, there is a huge inefficiency when it is time to deploy the new configuration because administrators are rebuilding everything in production instead of moving it.

Basics

Changes sets allow administrators to build and test their declarative configurations in a sandbox, then package and push the new functionality to another org (such as production) so that it can be deployed or further tested. They allow you to package any configuration that was completed through the setup menu including:

• Buttons and links
• Criteria based sharing rules
• Record types
• Custom objects & fields
• Flows
• Apex triggers
• …and a lot more.

It is important to note that there are some items that cannot be transferred via a change set. Become familiar with the limitations of this functionality as you will need to plan accordingly when moving configuration to a new org. It is also important to keep in mind that change sets only transfer meta data – not actual data (such as account or contact records). This information will need to be migrated using DataLoader or similar application.

Inbound vs Outbound

There are a few steps in creating a change set but it is fairly easy and straight forward. Once the configuration has been completed and it is time to migrate it to another org, a deployment connecting needs to be created. Deployment connections authorize the data to move from one org to another. Administrators can create multiple deployment connects in order to send or receive configuration from other orgs.

When creating a deployment connection, you must indicate where the data will be flowing from and where it will flow to. This is the difference between an inbound and outbound connection. If I am sending configuration from my sandbox to production, I would create an outbound change set from sandbox (data is flowing from this location) and an inbound change set in production (data will be received in this location).

Keep in mind that deployment connections need to be made in both the sending and the receiving org for change sets to work. There are only a few clicks when creating an inbound or outbound change set:

Setup | Inbound Change Sets or Setup | Outbound Change Sets

Once your deployment connections are set, there is typically no need to update them unless the sandbox is refreshed.

Best Practices

Creating change sets are easy and require a lot less time than rebuilding everything in production. Below is a video that walks you through the process of creating a change set and deploying it to another org. Here are some best practices that should always be considered when using change sets.

• Rename duplicate configuration – the beauty of a sandbox is that you can create multiple fields that do the same thing if there is a need to test functionality so that your process can be executed without a hitch. What this means though is that when it comes time to create a change set, it may be confusing as to which field is which. Prior to building the change set, it may be a good idea to rename the fields that won’t be transferred so that there is no confusion. This will save lots of time.

• Document the new configuration – as part of the process for developing in sandbox, it is a good idea to document the new fields, workflow rules, page layouts and other pieces of information that will need to move to the new org. This is especially true when a project may be spanning a month or longer. Open a Google Sheet or whatever your preferred tracking tool is and document what is being created. You’ll find this document helpful in no only building and deploying the change set, but testing and validating the change set after it is deployed and for updating your configuration workbook and other system documentation.

• Add visibility settings to the change set – typically the configuration built needs to be accessible to a group of users based on profile. Indicate which profiles should have access to the new functionality on the change set itself to save time. If skipped, it will require that every profile be individually updated to allow access to the configuration. This is a HUGE time saver.

• Validate – once the change set has moved to your inbound org, be sure to validate the package. This is especially true for production. The validation process will simulate the actual deployment and determine if there are any errors that need to be fixing. Typically, this is a missing field or permission on profiles. The error can be fixed and a new validation can take place. Once the package validates, you are ready to deploy knowing that all functionality is accounted for.

• Test – even if your configuration is validated and deploys without issue, there is still a need to test the functionality. Be sure to check that users have the appropriate level of access by logging in as a specific user to validate. Double check workflows and page layouts as well. In my experience, I have found a small number of items that needed to be adjusted in order for the functionality to be fully visible in production. Don’t skip this step!

This is a great video that outlines the full process of creating a change set and some additional best practices. Watch this video to help get a better understanding of the process.