The method developers use to deploy changes between different Salesforce environments is undergoing a radical change. It can be a daunting experience for many administrators since it will possibly be their first experience with Salesforce development operations. Even though many developers believe the future of Salesforce lies in DevOps and change sets are on their way out, even today a section of Salesforce developers still feels change sets remain relevant and important because of their ability to act as a bridge between the worlds occupied by developers and admins, something that DevOps may not deliver in user-friendliness.
Data vs. Metadata – What’s the Difference
Salesforce defines data as the information stored in the system, like sales records, customer information, etc. Metadata, on the other hand, refers to the configuration of the information within the system, defining the structure of the data and the way the system will process and display it.
Change Sets
Change sets are a deployment tool for transferring customizations from one Salesforce organization to another. Change sets allow administrators or developers to package together a set of changes they have made in one organization, such as new or updated objects, fields, validation rules, workflows, and more, and then move them to another organization.
Change sets are useful for organizations with multiple Salesforce environments, such as a sandbox and a production environment, where changes can be made and tested before deploying to production. Change sets can also move customizations between organizations in different Salesforce instances, such as between a partner and a customer organization.
According to Salesforce, developers can create and manage change sets using the Salesforce Setup menu. After creating a change set, developers can send it to another Salesforce organization for deployment. The receiving organization can review the changes and deploy them to its environment. They can also track salesforce change sets for compliance and audit purposes.
Types of Change Sets in Salesforce
In Salesforce, change sets move metadata (such as custom objects, fields, workflows, etc.) between different environments, like from a sandbox to a production environment. There are several types of change sets in Salesforce, including:
Outbound change sets: These package metadata changes from one environment, such as a sandbox or developer edition, and send to another environment, like a production environment.
Inbound change sets: These receive metadata changes in an environment. For example, an inbound change set can receive changes sent from a sandbox environment.
Unmanaged packages: These are similar to outbound change sets, but change sets do not control them. They can move metadata between environments or distribute metadata to other organizations.
Managed packages: They distribute and manage custom applications and functionality developed by Salesforce partners. Managed packages include metadata components any Salesforce organization can install.
Extension packages: They extend and enhance the functionality of managed packages. They include additional metadata components that developers can install along with the managed package.
Conclusion
Each change set type serves a different purpose and can be used to move metadata changes between different Salesforce environments. While many developers are moving away from change sets to DevOps-focused development, change sets remain a good way of understanding the development process and how they can deploy metadata between different environments.
