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.
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
- 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.
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.
9 thoughts on “ Saving Time With Change Sets ”
Since Few days I am trying to deploy first development in sandbox to production through change set. However, when I validate it shows few errors, I have tried to fix up most of them. However, some are not able to be fixed up, part may be cause it is my first time and part I am not sure of.
I have added all the components in the change set, that are part of this new development,
There is a VF page, an Apex Class controller referenced in that VF page and two custom objects with some new custom fields. I have also created one Apex test class to fix up some issues.
If you can provide me an email id of your’s I can send in the image of validation status.
Hello Nitesh! I would suggest posting this directly to the Salesforce Success Community. You’ll get a faster (and probably more accurate) response by posting it there. Click here to post a question.
Awesome Video and explanation, Brent. Thanks.
I’m going for Advanced Admin Certification next week.
Good luck on your certification!
Brent, what happened to your video? I just accidentally blew away all my config work when first trying to deploy this morning reading an official SF deployment page instead of the How to Deploy with Changesets page, so I’m eager to make sure I do it right this time.
Will cloning an outbound change set give you the latest metadata even if you’ve updated an element prior to clone. Use case is this: I add a quick action to a change set and upload. I get an error on validation in production. I then make my change in dev, save, and clone the change set. Will my changes be in the cloned change set?
As far as I’m aware Andy, it will take the most recent configuration/status of the metadata before you perform the clone of the change set.
Is it true that I can run a validation with just 1 apex test class vs testing my change set with my entire org?
Hey Nick, I’m not sure that I understand the question. Were you able to find the answer you were looking for?