Change sets in Salesforce: A Complete Guide

Change sets in Salesforce are the built-in functionality utilized to migrate customizations in metadata between sandboxes and the production environment. Metadata changes include new field creation, Flows, Apex triggers, email templates etc.

In this article, we will explore the details of change sets and how to create and deploy them, along with sharing best practices and discussing their limitations.

Required Permissions for Creating Change Sets

To create and manage change sets in Salesforce, specific system permissions are required.

• Editing the deployment connections between sandboxes and production requires the “Deploy change sets AND Modify Metadata Through Metadata API functions” permission.
• Using outbound change sets requires the “Create and upload change sets” permission.
• Using inbound change sets requires the “Deploy change sets AND Modify Metadata Through Metadata API functions” permission.

You can assign these permissions to users through permission sets or add them to their profiles.

Types of Change Sets

Salesforce offers two rent types of change sets: outbound and inbound change sets.

Outbound Change Sets

Outbound change sets to send changes from a source sandbox to a target sandbox or production environment.

For instance, if you’ve developed and tested new functionality in a sandbox and need to deploy it to production, an outbound change set lets you bundle these changes and move them securely.

Inbound Change Sets

Inbound change sets receive changes sent from other Salesforce org using outbound change sets. They enable users to review, validate and deploy the received changes in the target environment.

For instance, if you’re managing multiple Salesforce environments, inbound change sets assist in bringing tested and approved changes into the production environment.

To migrate change set from one Salesforce org to another, an administrator in the receiving org authorizes inbound change set uploads using the deployment connection linking the two orgs.

How to create Change Sets?

Follow these steps for creating a change set:

1. Go to your Salesforce org’s setup section by clicking on the ⚙ icon in the interface.

2. In the Quick Find box search “Outbound Change Sets” and choose it.

3. Press the “New” button and initiate the creation of a fresh outbound change set.

It’s a best practice to include descriptions in outbound change sets, as this will assist the team in future debugging efforts.

4. Under the change set components section, click the add button to add the components you need into your change set. This could involve custom objects, fields, workflows, triggers and other components.

To check the eligible components that can be migrated using change sets, click here

5. Browse the components you wish to include in the outbound change set by clicking on the Component Type drop-down, then click the “Add to Change Set” button.

6. Once you’ve included the components in the change set, you’ll find them displayed in the section dedicated to change set components.

7. To upload the change set components to the production environment, click the upload button and select the target org where you want to migrate these change set components.

8. Remember, once a change set is uploaded, its components remain unchanged, and it’s not possible to add or remove any components from the change set.

9. After successfully uploading all the components, a success message will appear.

How to deploy Inbound Change Sets?

When the uploaded outbound change set reaches its destination, it transforms into an inbound change set for that Salesforce org.

In the quick find box of the target org search “inbound change sets” and select it.

In the “Change Sets Awaiting Deployment” section, you can find the change set that was deployed from the source org.

By clicking on the change set name, you’ll access all the details associated with this specific change set.

Before deploying, validate your changes by clicking the “Validate” button. Choose the appropriate test option for validating your metadata components.

After a successful validation, the inbound change set gets deployed. Upon a successful deployment, you will be presented with the screen shown below.

Also Read – Salesforce Deployment Tools

Common Change Set Errors

• Cross-version validation error – This error occurs when the Salesforce org that made the outbound change set is using a different version than the target org.
• Component dependency error – This error arises when the dependent components being deployed via change sets rely on main components that are missing in the target org.
• Test class Failures – This error means the chosen Apex trigger lacks sufficient test coverage, a minimum of 75% coverage of Apex classes is required by the test class.
• Exceeded Governor Limits – This error happens when a deployment surpasses Salesforce’s governor limits, such as DML or SOQL queries. To prevent limit exceedance, split large deployments into smaller Change Sets.

Limitations of Change Sets in Salesforce

Although change sets make deployment and collaboration of metadata easier, they do come with some limitations:

• Deployment using change sets is supported only among the connected Salesforce orgs.
• Deploying a change set is accomplished within a single transaction. If something goes wrong, the whole thing is abolished. After a successful completion, all modifications become permanent and cannot be reverted.
• If an error happens during change set validation or deployment, you must initiate the process manually again. Make sure your org isn’t locked or undergoing maintenance. This can be a hurdle for continuous integration and deployment setups.
• Change sets don’t have versioning. This means you can’t keep different versions of the same deployment component in the same Change Set.
• Private reports cannot be added to change sets, and while unfiled public reports can be added, they won’t actually be deployed. To use change sets for the deployment of private and unfiled public reports, move these reports to a different folder.

Best Practices

• Before you deploy an inbound change set, it is highly recommended to validate the components to ensure they work well with the target Salesforce org.
• Ensure that every outbound change set includes all components that depend on each other and are absent in the target org.
• In case you have components that rely on others to be included in a previously uploaded change set, clone the change set, incorporate the dependent elements and then upload the duplicated change set.
• To deploy profile settings using change sets, include them in the “Profile settings for included components” section of the outbound change sets.

Conclusion

Salesforce change sets provide a streamlined solution for deploying changes, making it convenient for developers and administrators to migrate changes between different sandboxes and production orgs. However, acknowledging the limitations of change sets is also essential.

For complex deployment requirements, you can consider exploring other third-party deployment solutions such as Copado.

Are you passionate about deepening your Salesforce knowledge and skills? Join our Slack community and connect with a thriving network of experts and learners. 

Sign up with saasguru now and unlock a world of opportunities.

Frequently Asked Questions (FAQs)

1. What is a Change Set in Salesforce?

A Change Set in Salesforce is a feature that facilitates the migration of metadata from one Salesforce environment to another, typically from a sandbox to production. It allows administrators and developers to move customizations like fields, objects, workflows, and Apex code in a secure and controlled manner. Change Sets are primarily used for deploying tested changes from a development environment to a production environment, ensuring the integrity and stability of the production system.

2. What are the Limitations of Change Sets in Salesforce?

Change Sets in Salesforce come with several limitations:

1. Environment Limitation: Change Sets can only be sent between orgs that are directly connected, such as from a sandbox to its corresponding production org.
2. Content Restrictions: Not all metadata types are supported by Change Sets. Some components may need to be manually configured in the target org.
3. Version Control Absence: Change Sets do not support version control, which can complicate tracking changes over time.
4. Manual Error Handling: If an error occurs during the deployment of a Change Set, it needs to be manually resolved, which can be time-consuming.
5. No Rollback Capability: Once deployed, Change Sets cannot be rolled back automatically. Any necessary reversions must be done manually.
6. Deployment as a Single Transaction: The entire Change Set is deployed as a single transaction. If any part of it fails, the entire Change Set deployment is rolled back.

3. How to Enable Change Sets in Salesforce?

To enable and use Change Sets in Salesforce, follow these steps:

• Deployment Connection Setup: First, establish deployment connections between the source and target orgs (like from a sandbox to production). This is done in the deployment settings in Salesforce Setup.
• Permission Assignment: Ensure that the user responsible for creating and deploying Change Sets has the necessary permissions. This includes permissions like “Create and Upload Change Sets” for outbound Change Sets and “Deploy Change Sets” for inbound Change Sets.
• Accessing Change Sets: Once the deployment connection is set up and permissions are assigned, Change Sets can be accessed and managed from the Setup menu. Users can create outbound Change Sets in the source org and manage inbound Change Sets in the target org.