Salesforce Admin Change Sets

Introduction

Deployment is one of the essential elements not only in development but also in operations. However, deployment is always not an easy task. Typically, deployment involves a series of steps, including deployment preparation tasks such as creating deployment lists, removing unnecessary metadata, and preparing test classes, deployment testing, actual deployment, and post-deployment testing. The process may vary depending on the business environment, but the overall steps are generally similar to what has been mentioned.

 

There are many ways to deploy your sandbox to a targeted sandbox or production. Deployment options are as follows:

• Change Sets
• Copado
• Workbench
• Ant
• DevOps Center

Copado is a third-party platform that supports deployment services (paid). Workbench and Ant, on the other hand, are free and closer to deployment tools.

My preference is to use Change Sets and Copado with Ant. I will cover the detailed information in another post.

For now, let's dive into today's topic, Change Sets.

 

Change Sets

Change Sets are a standard feature provided by Salesforce. They are not available in all orgs, but can be used in a production org and its child orgs.

• Production org -> Child org: Yes
• Child org -> Production org: Yes
• Child org -> Another child org: Yes
• Production or child org -> different production org or its child org: No
  
  * Deployments in Salesforce do not involve data migration. They include permissions, settings, classes, etc., but do not include record data.

In my personal opinion, Change Sets are not suitable for large-scale deployments but are useful for small-scale deployments. They offer the Quick Deploy feature through Validation, which is particularly useful during the operational phase.

 

Who Can Use Change Sets?

If you're an admin user, you inherently have permissions. However, if you want to have a user who manages Change Sets only, you'll need to grant permissions accordingly.

 

Profile -> System Permissions

 

 

Set Up Before Getting Started

In the source org,  Setup -> Deployment Settings -> Click the targeted org's edit button -> Activate Allow Inbound Changes.

 

Outbound Change Sets

Outbound Change Sets is where you define and upload Change Sets to the targeted org.

 

Setup -> Change Sets -> Outbound Change Sets

Select the component you want to deploy and click the Add button.

Click Upload and select the target organization.

 

The upload process may take some time. It can be as quick as within a minute for smaller uploads, but for larger sizes, it could take over 10 minutes. Once the upload is complete, you will receive a notification via email.

 

Inbound Change Sets

Inbound Change Sets refer to the Change Sets that have been uploaded into the destination org. Let's navigate to the designated org specified as the target to check the Inbound Change Sets.

 

If there are no Apex classes in the uploaded Change Sets, you can proceed with deployment right away. However, if there is at least one Apex class in the Change Set, it must pass through validation via testing before deployment.

Generally, deployment via Change Sets is a partial deployment. Therefore, you should click on "Run specified tests" and specify the test classes to proceed with the deployment.

https://www.salesforcetutorial.com/quick-deployments-salesforce/

 

Conclusion

One useful aspect of using Change Sets is the ability to upload and validate during working hours. Once the validation is successful, you can perform a "Quick Deploy" without the need to run tests again for approximately 9 hours. Preparing deployments in advance allows you to proceed with deployment immediately at the designated time, and if no one else has deployed between validation and deployment, the deployment can proceed seamlessly, potentially allowing you to leave work on time.

 

Reference

https://help.salesforce.com/s/articleView?id=sf.changesets.htm&type=5

https://www.salesforceben.com/everything-you-need-to-know-about-salesforce-change-sets/