Salesforce Change Set : A Complete Guide

Salesforce is one of the most powerful customer relationship management (CRM) platforms. But, as you build and customize Salesforce for your business, you may need to move changes from one Salesforce org to another. This is where Salesforce Change Set come in.

In this guide, we’ll explain everything you need to know to use Salesforce Change Sets effectively.

Understanding Data & Metadata

Before diving into Change Sets, it’s important to understand the difference between data and metadata.

Data

Data refers to the actual information or records that are stored in your Salesforce environment.

Metadata

Metadata refers to the structure or definition of your Salesforce environment. It tells what should exist in your environment (objects, fields, page layouts, etc.) and how it should be structured.

When using Salesforce Change Sets, you’re working with metadata. This means you can move the structure of your custom objects, fields, workflows, and other configurations between environments.

Note : Data cannot be moved through Change Sets, meaning you won’t be able to transfer actual records between environments using this tool.

What is Salesforce Changes Set?

A Change Set in Salesforce is a feature that help to move metadata between environments, usually from sandbox to production.

Change Sets allows developers and administrators to transfer metadata, such as fields, objects, workflows, and Apex code, from one environment to another. This ensures that changes are transferred safely and consistently and keeping the live system reliable.

Want to know more about Sandboxes in Salesforce? Check out this in-depth guide

Types of Salesforce Changes Sets

In Salesforce, there are two types of Change Sets that help you move changes between different Salesforce environments, like from a sandbox (test environment) to production (live environment). These are:

Outbound Change Set

An outbound change set is created in the source Salesforce org (like your sandbox or test environment). It includes the changes you want to move to another Salesforce org (typically, the production org).

Inbound Change Set

An Inbound Change Set refers to a change set that is received in a destination environment (such as production) after being sent from a source environment (like a sandbox).

Aspect	Outbound Change Set	Inbound Change Set
Creation Location	Created in the source org (sandbox)	Received in the destination org (production)
Deployment Purpose	This type of change set allows you to package and deploy changes made in the source Salesforce org to another org.	This type of change set allows you to deploy and apply the changes that were sent from another org (typically from a sandbox to production).
Example	You are working in a sandbox environment and have created a custom object called Invoice with several fields. You can create an Outbound Change Set to package the Invoice object, its fields, and then deploy it to the production environment.	After the Outbound Change Set containing the Invoice object was uploaded from the sandbox to the production environment, it now appears as an Inbound Change Set in the production org. In the production environment, an admin will review the inbound change set, validate the changes, and then deploy them.
Visibility	Visible only in the source org	Visible only in the destination org

Permissions Needed to Use Change Set

To use Change Sets in Salesforce, both for creating and deploying them, certain permissions are required. The necessary permissions depend on the type of action you’re trying to perform (such as creating an outbound change set or deploying an inbound change set).

Here’s an Summary Table that help to understand the permissions required for working with Change Sets in Salesforce:

Action	Required Permission	Description	Who Needs It?
Create and Upload Outbound Change Sets	Deploy Change Sets	Grants the ability to create and upload outbound change sets (sending changes to another org).	System Administrators or users with custom profiles and permissions.
	Modify All Data	Provides full access to all records and data in Salesforce, helping with managing components in change sets.	Recommended for users who need to handle all components of change sets (like objects, fields, etc.).
	View Setup and Configuration	Allows users to access the setup menu and configuration pages needed to create change sets.	Users who are responsible for managing changes to Salesforce metadata.
Deploy Inbound Change Sets	Deploy Change Sets	Grants the ability to deploy (apply) inbound change sets that have been sent from another org (like a sandbox).	Users who will deploy changes in production or other target environments.
	View Setup and Configuration	Allows users to see and validate inbound change sets before deploying them.	Admins or other users who will review and deploy changes.
	Author Apex (if Apex code is included)	Necessary for deploying Apex classes, triggers, or other code-based components that might be included in the change set.	Users deploying change sets that include Apex-related components.
View and Validate Change Sets	View Setup and Configuration	Provides permission to view and validate the components of an inbound change set before deployment, without being able to deploy them.	Users who will review the change set but not deploy it (e.g., admins or developers).
	View Change Set History	Allows users to view previously deployed change sets and their deployment status.	Users who need to track past deployments and changes.

Note

• In most organizations, System Administrators will typically have all the necessary permissions to both create and deploy change sets.
• However, these permissions can be adjusted via Profiles or Permission Sets to allow more specific user roles to handle change set creation and deployment as needed.

Getting Your Org Ready for Change Sets

Before creating a change set, you need to set up the deployment connection between your source and target orgs. Below are the steps we define to ensure your org is set up to send and receive change sets:

1. Go to Deployment Settings in Setup.
2. Click Edit next to the sandbox or org where you want to create the change set.
3. On the next screen, you’ll see options to enable inbound and outbound changes:
   • Inbound changes are those sent from other orgs.
   • Outbound changes are those you wish to send from your current org to another org.

Creating an Outbound Change Set

Once you’ve added the components to the change set, you’ll find them in the change set components section.

Uploading Change Set to the Target Org

Once your change set is ready, the next step is to upload it to the target org:

Upload the Change Set

1. After adding all the necessary components, click the Upload button.
2. Choose the target Salesforce org (typically a sandbox or production org).
3. Salesforce will upload the change set to the selected org.

Confirm the Upload

After the upload is complete, a confirmation message will appear, indicating that the change set is now ready for deployment in the target org.

Deploying an Inbound Change Set

After an outbound change set is uploaded from the source org, it becomes an inbound change set in the destination org. To apply the changes from the inbound change set to your org, follow these steps:

Access & Review Inbound Change Sets

1. In your target Salesforce org, go to Setup by clicking on the gear icon.
2. In the Quick Find search box on the left, type “Inbound Change Sets” and select the Inbound Change Sets option.
3. You will see the list of change sets that have been uploaded. Click on the change set you want to deploy.
4. Review the components included in the change set to ensure that all necessary changes are correct and ready for deployment.

Validate & Deploy the Change Set

In the “Change Sets Awaiting Deployment” section, you’ll find the inbound change set that was uploaded from the source org. By clicking on the change set name, you’ll be able to access all the details and components included in this change set.

1. You can choose to validate the change set before deploying it. This step will check for any potential errors or conflicts that might occur during deployment.
2. Click Validate to run the validation.
3. After the validation is complete, you’ll receive a summary of any errors or warnings that need attention before proceeding with deployment. If everything looks good, you can proceed to deploy the change set.

1. Once you’re confident that the change set is ready, click Deploy to apply the changes to the target org.
2. Salesforce will apply the changes, and you’ll receive a success message once the deployment is complete.

Monitoring Deployment Status

After starting your change set deployment, you can check its status by going to the Deployment Status page in Setup. This page displays a list of all your previous deployments, along with their current status.

If there are any issues with your deployment, such as errors or failures, you can find detailed information here to help identify and fix the problem. Follow these steps:

Navigate to Deployment Status

1. In your target Salesforce org, go to Setup by clicking on the gear icon.
2. In the Quick Find search box on the left, type “Deployment Status” and select the Deployment Status option to Open it.
3. On the Deployment Status page, you will see a list of all your previous deployments, including their current status (e.g., In Progress, Completed, or Failed).

View Deployment Status

1. Find the change set you want to check and click on the View Details button next to it.
2. On the Detail page, look for a green circle. This indicates that your component has been successfully deployed to the production org.
3. If there are any errors or warnings, they will be listed here, providing detailed information to help you identify and resolve the problem.

Limitations of Change Sets in Salesforce

Change Sets have some limitations that can make them challenging to use effectively, especially for larger or more complex deployments. Here are some key limitations:

Not Deploy All Metadata Components at Once

With Salesforce Change Sets, you can’t deploy all metadata components together. For example, if you’re deploying custom settings and a Visualforce page that uses them, you need to deploy the custom settings first, then create a separate Change Set to deploy the Visualforce page.

No Easy Way to See What’s Different

Change Sets don’t clearly show what’s changed between your source and target environments, making it difficult to keep track of updates and differences.

Manual and Time-Consuming

Developers have to create separate Change Sets for each deployment step (e.g., from development to QA, then to UAT), which can take a lot of time.

No Built-in Version Control

Change Sets can’t integrate with version control systems like Git, making it harder to track changes, work in teams or Roll back to previous versions if something goes wrong.

Limited Deployment Options

Change Sets offer limited control over deployments. You can’t easily deploy only selected changes, schedule deployments at a specific time, or automate the deployment process.

Full Failure on Errors

If an error occurs during deployment, the whole Change Set fails and is rolled back, so you must manually fix the issue and try again.

No Rollback

Change Sets don’t support versioning, so once changes are deployed, you can’t roll them back or maintain different versions.

Only Works Between Linked Accounts

Change sets only work between Salesforce organizations that are directly connected. You can’t use them to deploy to just any Salesforce org.

Alternatives to Salesforce Change Set

While Change Sets are a valuable tool for many Salesforce deployments, but they have a few drawbacks that may make them less suitable for large-scale or frequent deployments.

Some alternatives that offer advanced deployment features, automation, and version control system integration are listed below:

Salesforce DX (SFDX)

SFDX is a modern development approach that improving the entire development process. It offers tools and best practices to help developers create and deploy high-quality Salesforce apps. With the Salesforce CLI (Command Line Interface), deployments become more automated and flexible.

Key Features

• Version Control Integration: integrates with Git for tracking changes and managing metadata.
• Scratch Orgs: Quickly create Salesforce development and testing environments with Scratch Orgs.
• CI/CD: Enables continuous integration and deployment for automated testing and releases.
• Salesforce CLI: Command-line tool for managing apps, running tests, and automating deployments.

Ant Migration Tool

The Ant Migration Tool is a command-line tool that allows you to automate the deployment of metadata between Salesforce orgs. It’s a powerful tool for developers who prefer a more hands-on approach.

Key Features

• Version Control Integration: Works with Git for better change tracking.
• Delete Component: A change set does not allow you to delete metadata components from the target org. However, you can delete components using the ANT Migration Tool by including a destructiveChanges.xml file.
• Error Handling: Provides detailed error logs for troubleshooting.
• Metadata Backups: Retrieves the metadata from your Salesforce org as XML files and saves them to your local computer..

DevOps Center

Salesforce DevOps Center is a newer tool designed to help improve and speed up the development and deployment processes within the Salesforce ecosystem. It makes it easier to manage changes and deployments by combining traditional development practices with modern DevOps methods.

Key Features

• Source Control Integration: Connects to Git for version control, enabling collaboration and change tracking.
• Change Tracking: Automatically tracks and associates changes with work items for better visibility..
• Environment Management: Easily manage different Salesforce environments (e.g., development, QA, production).
• Automated Deployments: Integrates with CI/CD tools to smooth and speed up deployments.

Third-Party Deployment Tools

Third-party deployment tools offer a wide range of features and benefits, including:

• Advanced features: Such as data migration, rollback, and reporting.
• User-friendly interfaces: Make it easy to manage and deploy changes.
• Automation: Reduce manual effort and increase efficiency.
• Integration with version control systems: Ensure code quality and collaboration.

Some popular third-party deployment tools include Copado, Gearset, Flosum, getjetstream and AutoRABIT.

Common Errors in Salesforce Change Set

Here are some common errors when using change sets in Salesforce, along with ways to fix them:

Apex Test Failures

Cause: Salesforce requires at least 75% test coverage for Apex code. If tests fail or coverage is too low, the deployment won’t work.

Solution: Ensure all Apex tests pass and have enough coverage before deploying. Fix any failing tests.

Incorrect API Version

Cause: Salesforce components (like Apex classes or triggers) are tied to a specific API version. If the source and target orgs have different versions, there could be compatibility issues.

Solution: Ensure that the API version of components in the source org matches the target org or is compatible.

Missing Dependencies

Cause: Some components depend on others to work. If these dependencies are not included in the Change Set, the deployment will fail.

Solution: Check for and include all required components. Use the “View/Add Dependencies” option to find and add missing components.

Validation Rule Errors

Cause: If the Change Set includes validation rules and existing data in the target org doesn’t meet these rules, the deployment will fail.

Solution: Check for any data in the target org that might violate the validation rules. Clean up the data or temporarily deactivate the rule during deployment.

Circular Dependencies

Cause: Salesforce doesn’t allow circular dependencies between components. For example, if two custom objects reference each other in a loop, it will cause an error.

Solution: Check the relationships between components to avoid circular dependencies, especially with custom objects and fields.

Component Validation Errors

Cause: Salesforce checks for errors in code or logic (e.g., Apex classes, triggers, validation rules) before deployment. If there are issues, the deployment will fail.

Solution: Before adding components to the Change Set, check for errors using tools like the Developer Console or Apex test classes.

Missing or Incorrect References in Formula Fields

Cause: If you have formula fields in the Change Set that reference fields or objects that don’t exist or have been renamed in the target org, the deployment will fail.

Solution: Check all formula fields to ensure they reference valid fields and objects in the target org.

Salesforce Change Set Best Practices

Here are some tips to make your Salesforce deployments more reliable and less stressful :

Organize Your Changes

• Group Related Changes: Put similar changes together in one change set.
• Keep It Small: Break large change sets into smaller ones.
• Name It Right: Give your change sets clear names to easily understand their purpose.

Test Thoroughly

• Test in a Safe Space: Test your changes in a sandbox environment before deploying to production.
• Check Your Code: Use unit tests to make sure your code works as expected.
• Get User Feedback: Ask real users to test your changes and provide feedback.

Communicate Clearly

• Keep Everyone Informed: Let people know about upcoming deployments and what to expect.
• Work Together: Coordinate with other teams to avoid conflicts.
• Document Your Changes: Write down what you changed, why, and any potential issues.

Deploy Smartly

• Choose the Right Time: Deploy during off-peak hours to minimize disruptions.
• Have a Backup Plan: Know how to undo changes if something goes wrong.
• Watch the Process: Keep an eye on the deployment and fix any problems quickly.
• Double-Check: After deployment, make sure everything works as it should.

Additionally, You can also learn more by checking out the official Salesforce documentation.

Conclusion

Salesforce Change Sets are a simple way to move changes between different Salesforce environments. They’re perfect for small projects and can help you work more efficiently.

But for bigger, more complicated projects, Change Sets might not be enough. You might want to consider using tools like Copado or others that offer more advanced features.

By understanding the strengths and weaknesses of different deployment tools, you can choose the best one for your specific needs.

FAQs