What you need to know about Salesforce change sets
Deployments have always been a topic of debate throughout the lifecycle of the Salesforce ecosystem. Today, as organizations increasingly adopt DevOps practices for their software delivery, the approach to Salesforce deployment has witnessed a notable shift.
Harald is the Co-Founder of Hutte, bringing his vision of no-code DevOps to life. His passion enables teams and individuals to focus on what matters most – bringing value to the users they build for.
Manuel Moya Ferrer is a highly skilled freelancer who serves as a technical architect, developer, and DevOps engineer. He specializes in Salesforce solutions, covering all technical aspects of their development lifecycle.
Article Highlights
Tools like Hutte and "dx@scale" are reshaping deployment strategies in Salesforce, providing structured solutions even when a full-fledged DevOps approach is not implemented.
Data refers to the actual information stored, while metadata, crucial in the context of Salesforce change sets, outlines the data’s structure and relationships, crucial for effective deployment.
Salesforce change sets offer a user-friendly interface that simplifies the selection and packaging of components, thereby reducing errors during the deployment process.
Beyond the conventional, open-source projects like "dx@scale" and tools like Hutte are reshaping deployment strategies and providing structured solutions. We also have Salesforce's DevOps Center, a new yet somewhat complex method for handling deployments.
🚢
The point is – even if a full-fledged DevOps approach isn't in play, some tools excel in bringing changes from one Salesforce org to another. For example, Copado Essentials and Hutte's 'deploy' functionality. Hutte's functionality, though not its primary deployment method, offers a swift and convenient way to ship individual changes.
Amidst these changes, the Salesforce change set continues to be a valuable tool in various scenarios. In this guide, I discuss everything you need to know about Salesforce change sets.
But, before understanding change sets, you need to understand the difference between data and metadata.
Data vs. metadata
Data, as we all know, refers to the actual information stored in a system, such as records, text, and numbers.
Metadata, conversely, is information about the data, providing context and structure. While data is content (such as customer names and purchase amounts), metadata encompasses details like data type, creation date, and relationships, offering insights into how the data is organized and interpreted.
What are change sets?
Salesforce change sets are an essential tool in the deployment process, offering a straightforward (but time-consuming) way to move configuration – metadata – changes between environments.
♻️
At its core, a change set is a container for grouping and migrating metadata changes, such as fields, workflows, and profiles, from one Salesforce organization to another.
This mechanism simplifies the often complex task of moving customization across different environments, ensuring consistency in the development, testing, and production phases.
Types of change sets:
Inbound change set: An inbound change set is a package designed to receive and deploy changes from one Salesforce organization to another.
Outbound change set: An outbound change set in Salesforce is a package created in the source organization to bundle and send changes to a target organization.
How change sets facilitate deployment in Salesforce
Change sets provide a user-friendly interface for Developers and Administrators to select and package components for deployment. This simplification is crucial for maintaining the integrity of configurations, as it reduces the likelihood of errors during the deployment process.
With an easy-to-understand UI, change sets act as a bridge between Admins and Developers. By encapsulating changes into a single unit, change sets help easily transfer data between Salesforce instances.
My experiences with change sets are nightmares of the past. Generally, this relates to the discussion of not using Git-based development, inheriting the disadvantages of this approach, despite the benefits of using the metadata API. Additionally, projects where change sets are still used often suffer from poor practices and processes during other phases of the development lifecycle, making them potential candidates for rework at many levels of the DevOps phases.
After understanding change sets, the next step is comprehending the components you can include in the change sets. These components range from custom objects, fields, and page layouts to workflows, validation rules, and Apex classes.
Here's a list of critical components that you can include in Salesforce change sets:
Custom objects
Custom fields
Page layouts
Record types
Workflows
Approval processes
Validation rules
Formula fields
Apex classes
Triggers
Profiles
Permission sets
Reports
Dashboards.
Creating a change set
Before entering the detailed steps of creating a change set, let's establish a clear scope of permissions you need.
Permissions required
In most cases, a user with an admin profile creates, manages, and deploys change sets. Meaning, an admin profile is already equipped with required permissions. In case you want other profiles to be able to create and manage change sets, make sure they have the following permissions:
Deploy change sets and modify metadata through metadata API functions
Create and upload change sets.
Planning change management
After checking and setting up permissions, the next step is establishing a clear change management plan. It can involve identifying the need for change, defining the deployment scope, execution, QA testing, and UAT.
But here are three non-negotiables:
Identify changes
Clearly define the scope of your changes. What components must be moved, and how will they impact users and processes?
Communication
Inform stakeholders about the upcoming changes. Transparent communication helps mitigate surprises and ensures a smooth transition.
Dependencies
Recognize any dependencies between components. Specific changes may rely on others, and understanding these relationships is crucial for a successful deployment.
Getting your org ready
Now, before you jump off and start with the change set creation, there is just one more step to follow. Prepare your Salesforce organization for the upcoming changes:
Back up your org
Perform a complete backup of your Salesforce organization to prioritize data integrity and ensure a safety net in case unforeseen issues arise during deployment.
Check limits and dependencies
Verify that you haven't exceeded any change set limits (I discuss it later in this article). Additionally, ensure that dependent components are included to prevent errors during deployment.
Configure deployment settings
Before creating your change set, configure the deployment connection in the target org. Navigate to "Deployment Settings" in "Setup," click "Edit" next to the desired sandbox, and configure the options for inbound and outbound changes.
Consider profiles and permissions
Assess the impact of the changes on profiles and permissions. Understand how changes may affect user access and security settings.
Creating a change set
Now that you're done with the pre-requisites, let's start with the steps to create a change set:
Log into your Salesforce org and go to "Setup." In the "Quick Find" box, type "Outbound Change Sets" and select it from the results.
Create a new change set by clicking the "New Outbound Change Set" button.
Name your change set and provide a description that clearly outlines the purpose and scope of the changes.
Use the "Add" button to include the components you identified during the planning phase. Be selective and careful!
After adding a component, the previously grayed-out "View/Add Dependencies" button becomes active. Use this to identify components dependent on your additions.
Once components are added and dependencies are reviewed, upload the change set. This action validates the components and prepares them for deployment.
Salesforce will now perform a validation check. Review any errors or warnings and address them before proceeding.
👉
Author's note: Know that there are some components that you can't deploy via change sets – for example, picklist values, email addresses, sales processes, etc. Hence, checking eligible components before you create change sets is advised.
Deploying your Salesforce change set
Now that your change set is ready, the deployment process in the target org can be initiated. Simply log into your inbound org and go to "Setup." Locate the "Inbound Change Sets" option. Once there, select the desired change set, and you will have three options:
"Validate"
"Deploy"
"Delete."
Validate
The first step is running a validation on the change set. This process assesses the readiness of the change set for deployment and identifies potential errors. For example, consider a formula field relying on another field. In this case, the validation stage would highlight any missing dependencies. A "Quick Deploy" option appears if the validation is successful, allowing you to bypass validation during the actual deployment.
Deploy
Deploy validates the change set and attempts to execute the changes in the target org.
Delete
This option deletes the change set. It is typically used if an error occurs, prompting the need to clone and upload a new corrected version.
Monitoring your deployment
Once the deployment is initiated, monitoring its progress is crucial. Go to the "Deployment Status" page in "Setup," where your deployment history is displayed. Any issues encountered during deployment can be found here.
While change sets provide a straightforward deployment process, there are essential considerations:
Limitations with profiles
Profiles may pose challenges in the change set process. Some Admins find it more efficient to push customization changes through change sets and then manually update profile permissions in production. However, Salesforce encourages using permission sets, which integrate seamlessly with change sets.
Rollback limitations
Changes made through change sets cannot be rolled back. Unlike certain DevOps solutions, the inability to quickly revert changes emphasizes the importance of thorough planning and testing before deployment.
Limitations of Salesforce change sets
A section highlights the limitations whenever Salesforce change sets are spoken about.
Honoring that tradition, here are key limitations associated with change sets:
Partial component support
As previously discussed, change sets do not support all Salesforce components. Components like standard org-wide email addresses, picklist values, and sales processes require manual intervention.
This limitation often leads to increased deployment time, the need for additional manual adjustments, and human errors.
Delivery chain challenges
Deploying a change set from one environment to another, such as from development to QA, may cause challenges in maintaining delivery chains. Say you deployed a change set for development to a QA environment. It worked well, and now you want to deploy the same set to production. Well, you can't.
You must clone, add dependent components, and reupload the change set to production deployment. These are some steps that hinder the establishment of chains, especially in organizations with multiple test environments.
Limitation on connected orgs
Change sets only support connected orgs. In scenarios where the same application is used across multiple organizations with separate production instances, establishing connections from production to production becomes impractical. This limitation results in increased deployment time, lack of feasibility, and redundant work.
Cumbersome element management
Creating significant change sets can be cumbersome. Scrolling through multiple pages, adding or removing components one by one, and the inability to add different types simultaneously pose challenges.
Things get harder when you accidentally add the wrong components. You can't help but remove them individually, delaying the process further. Admins might resort to browser extensions for efficiency, which could compromise compliance and speed.
Absence of risk analysis
Change sets lack built-in risk analysis capabilities, making it challenging to communicate potential risks to end-users beforehand. This absence increases deployment vulnerability and reliance on external risk-identification apps, impacting the overall reliability of the deployment.
Integration challenges with version control systems
Change sets lack integration with version control systems like Git/SVN. This absence requires extra effort to identify changes from source control and manually push them individually. Organizations may need to resort to third-party tools or cloud-based solutions like Jenkins for a more streamlined integration.
No rollback support
This is probably the most significant limitation. Deploying change sets to a destination org is a final action with no native rollback support. In case of deployment failures or unexpected issues, reverting changes involves a manual and time-consuming process, leading to potential business disruption and loss.
Common change set errors in Salesforce
Although you can't roll back wrong changes, you can stay alert. Recognizing some common issues and understanding how to address them is helpful, especially in the case of change sets.
Here are several standard change set errors and ways to resolve them:
Cross-version validation error
This error occurs when the Salesforce org creating the outbound change set uses a different version than the target org.
Resolution: Ensure the source and target orgs run the same Salesforce version. Aligning versions helps prevent compatibility issues during deployment.
Component dependency error
This arises when dependent deployed components rely on main components missing in the target org.
Resolution: Before deployment, thoroughly check for and include all necessary main components that dependencies rely on. Use the "View/Add Dependencies" feature to identify and add any missing components.
Test class failures
Such failures indicate that the chosen Apex trigger lacks sufficient test coverage, with a minimum of 75% coverage of Apex classes required by the test class.
Resolution: Review the test coverage for the Apex trigger. Create or update test classes to ensure they meet the minimum coverage requirements before attempting the deployment.
Exceeded governor limits
Such errors occur when a deployment surpasses Salesforce's governor limits, such as DML or SOQL queries.
Resolution: Split large deployments into smaller change sets to prevent limit exceedance. Consider optimizing the deployment by reducing the number of components in each set.
Metadata type mismatch error
This error arises when attempting to deploy components with mismatched metadata types between the source and target orgs.
Resolution: Review the metadata types of the deployed components and ensure they are compatible with the target org. Adjust configurations or choose alternative deployment methods if necessary.
Permission set assignment errors
Permission errors occur when attempting to deploy changes related to permission sets, and there are discrepancies in the assignment between source and target orgs.
Resolution: Verify and synchronize permission set assignments between the source and target orgs. Confirm that users in the target org have the appropriate permissions aligned with the deployed changes.
Inactive component errors
These errors arise when deploying inactive or deactivated components in the source org but are still referenced by other active components.
Resolution: Activate or reactivate the referenced components in the source org before attempting the deployment. Ensure that all components included in the change set are in an active state.
Who hasn't had to use them for lack of alternatives, and who ever had something positive to say about Change sets?
Harald Mayer
Hutte CEO & Founder
Ship your changes hassle-free
Despite the emergence of DevOps methodologies and tools, Salesforce change sets still serve as a base tool to bring metadata from org 'A' to org 'B' if no better tool is available.
⬇️
If you need more detailed assistance on how to conveniently ship individual changes, don't be shy to contact us at Hutte. Our team has a tailored change set solution made just for you.
This feature allows for the automation of repetitive tasks and workflows, which could be leveraged to streamline test case creation and execution in Salesforce testing.
Prompt Builder enhancements
Users can now create, test, and refine prompt templates without coding. This tool could be particularly useful for setting up test scenarios in automated testing frameworks by dynamically incorporating CRM data.
Service Cloud Einstein
This feature enhances the capability to automatically surface relevant answers from Knowledge Articles. It could be adapted for automated testing to verify the accuracy of data retrieval and the logic of Salesforce applications.
Commerce Concierge
This AI-powered tool simplifies conversational interactions, which can be applied to simulate user actions in test cases for B2B Salesforce environments, ensuring that automated tests cover complex user interactions effectively.
Sushrut is a skilled Salesforce Developer, Technical Writer, and Entrepreneur. His expertise includes front-end dev, Web3, and DevRel. He leverages technology to craft exceptional digital experiences.
