Change Sets in Salesforce – deployment tools

In our previous Salesforce tutorial, we have learned about What is Salesforce Sandbox, What are the different Salesforce Sandbox Types, How to create Sandbox model in Salesforce and how to login Salesforce Sandbox. In this Salesforce Training tutorial, we will learn about deployment tools in Salesforce, how Change Sets in Salesforce work, and when a change set is the right deployment choice.

After creating Salesforce Sandbox, teams usually build and test configuration changes in a sandbox before moving approved metadata to production. This movement of setup configuration is part of Salesforce application lifecycle management, also called change management or metadata deployment. Choosing the correct deployment tool matters because a small declarative update, a large release, and a source-control-driven project need different handling.

Deployment tools in Salesforce for moving metadata between orgs

Some commonly used deployment tools in Salesforce are listed below. Older tools may still appear in legacy tutorials or existing org processes, but most current projects use Setup-based change sets for simple admin deployments or source-driven tools for larger releases.

1. Change sets.
2. Salesforce CLI and Metadata API for source-driven deployment.
3. Salesforce DevOps Center for tracked, release-based changes.
4. Visual Studio Code with Salesforce Extensions for development projects.
5. Workbench for selected metadata and package operations.
6. Force.com Migration Tool, Eclipse Force.com IDE, and MavensMate in older or legacy workflows.

For official reference, Salesforce documents the Setup path, deployment connections, outbound change sets, inbound change sets, and best practices in its Change Sets, Deploy Using Change Sets, and Change Sets Best Practices help pages.

Change Sets in Salesforce for sandbox-to-production deployment

Change sets in Salesforce are collections of metadata components that are uploaded from one connected Salesforce org and deployed into another connected Salesforce org. A common example is creating an outbound change set in a sandbox, uploading it to production, validating the inbound change set in production, and deploying it after tests pass.

Change sets are declarative because the whole process is handled from Salesforce Setup using point-and-click screens. They are suitable for many admin changes such as custom fields, page layouts, record types, permission sets, flows, validation rules, email templates, and selected automation metadata. They are not a replacement for version control, release branching, automated CI/CD, or a full DevOps process.

What Salesforce metadata means in a change set

Metadata describes the configuration and structure of a Salesforce org. Examples include custom objects, fields, page layouts, Lightning pages, permission sets, flows, validation rules, Apex classes, triggers, profiles, and record types. Business data such as Account records, Contact records, and Opportunity records is not moved by a change set.

The Force.com IDE, Force.com Migration Tool, Salesforce CLI, Metadata API, Workbench, and browser-based Setup tools all work with metadata in different ways. A change set is the Setup-based option for packaging supported metadata components and sending them between connected orgs.

Before using Change Sets in Salesforce: deployment connection, access, and testing

Before you create a Salesforce change set, confirm that the source org and target org are connected through Deployment Settings. For example, if a sandbox must send changes to production, production must allow inbound changes from that sandbox. The user performing the deployment must also have the required setup and deployment permissions in the relevant org.

• Use a sandbox as the source org. Build and test the change in a sandbox before uploading it to production.
• Enable the deployment connection. In the target org, go to Setup, search for Deployment Settings, and allow inbound changes from the source org.
• Prepare dependent components. Add related fields, record types, permission sets, layouts, flows, and Apex classes that are required by the main change.
• Run tests before deployment. Validate the inbound change set first, especially when Apex, flows, validation rules, or security changes are included.
• Plan a rollback approach. A change set deploys metadata, but it does not automatically create a one-click rollback package.

How to deploy change sets in Salesforce from sandbox to production

The basic process for deploying a change set in Salesforce is to prepare the source sandbox, upload an outbound change set, and deploy the inbound change set in the target org. The steps below describe the usual sandbox-to-production path.

1. Create a sandbox in Salesforce and complete the configuration changes in that sandbox.
2. In the target org, open Deployment Settings and allow inbound changes from the source sandbox.
3. Log in to the sandbox and create an outbound change set from Setup.
4. Add change set components such as custom fields, page layouts, flows, permission sets, Apex classes, and dependent metadata.
5. Upload the outbound change set to the target production org.
6. Log in to production, open Inbound Change Sets, and review the uploaded package.
7. Click Validate to run deployment checks without applying the changes.
8. After validation succeeds, click Deploy to apply the inbound change set.
9. Test the affected feature in production and verify user access, page layouts, reports, automation, and integrations.

Upload Outbound Change Set in Salesforce

An outbound change set in Salesforce is a change set created in the Sandbox environment in which you are logged in and to send to production environment. You typically use an outbound change set for customizations created and tested in a sandbox and that are then sent to a production org.

To create one, go to Setup in the source sandbox, search for Outbound Change Sets, create a new change set, add components, add profiles or permission sets when access settings are required, and then upload the change set to the connected target org. Give the change set a clear name such as Case Layout Update – June Release so the inbound reviewer understands what is being deployed.

Deploy Inbound Change Set in Salesforce

An inbound change set in Salesforce is a change set that has been sent from another Salesforce org (Sandbox environment) to the org(production environment) you are logged in to. A change set must be deployed for the changes to take effect. You can deploy the contents of an inbound change set as a whole, but not on a component-by-component basis.

In the target org, open Inbound Change Sets from Setup, review the uploaded components, validate the change set, inspect any errors, and deploy only after validation is successful. Salesforce provides separate guidance for deploying inbound change sets, including validation and deployment behavior.

Salesforce change set components commonly included in releases

A change set should include the metadata needed for the target org to understand and run the change. Missing dependencies are a common reason for validation errors. The exact component list depends on the feature being deployed.

Deployment need	Typical change set components to review
New field on an object	Custom field, page layout, Lightning record page, permission set or profile field access, report type if used
New record type	Record type, business process if applicable, page layouts, picklist values, permission assignments
Updated automation	Flow, custom labels, email alerts, email templates, fields, permission sets, Apex classes if called
Apex deployment	Apex class, trigger, test class, custom metadata, permission sets, connected settings used by the code
New user access model	Permission sets, permission set groups, custom permissions, object and field permissions, app permissions

Change set limitations in Salesforce and when another deployment tool fits better

Change sets are useful for small and medium declarative releases, but they have practical limitations. Use another deployment tool when the release needs repeatable automation, source control review, multi-org promotion paths, or a larger DevOps process.

• Change sets work only between connected related orgs. They are not a general tool for moving metadata between any two unrelated Salesforce orgs.
• They are manual and Setup-based. Admins must add components, upload, validate, and deploy through the Salesforce UI.
• They do not provide version control. A change set does not show a Git-style history of why each metadata file changed.
• They deploy as a package. You cannot choose only one component from an inbound change set during deployment.
• Dependencies need careful review. Salesforce can detect many missing dependencies, but release owners should still check related metadata before upload.
• Some metadata types may not be supported or may require another tool. For source-driven development, Salesforce CLI and Metadata API are usually better choices.

Practical Salesforce change set example: deploying a custom Case field

Assume an admin creates a custom field named Escalation Reason on the Case object in a sandbox. The field appears on the Case Lightning record page, is added to a page layout, and is visible to support agents through a permission set.

1. Create and test the custom field in the sandbox.
2. Add the custom field to the outbound change set.
3. Add the Case page layout or Lightning record page if the UI was changed.
4. Add the permission set or profile settings needed for field access.
5. Add any reports, list views, validation rules, flows, or email templates that reference the field.
6. Upload the outbound change set to production.
7. Validate the inbound change set in production.
8. Deploy and test with a user who has the intended support agent permission set.

Troubleshooting Salesforce inbound change set validation errors

When an inbound change set fails validation, read the first error carefully and identify the missing or conflicting component. Many deployment errors are caused by an object, field, Apex test, permission, or automation dependency that was not included in the outbound package.

• Missing field or object: Add the referenced metadata component to the outbound change set and upload a new version.
• Apex test failure: Review the failing test method, required test data, validation rules, and recent automation changes.
• Flow activation issue: Confirm that all fields, record types, email alerts, custom labels, and Apex actions used by the flow are available in the target org.
• Permission issue: Check whether the correct permission sets or profile access settings were included.
• Duplicate or conflicting metadata: Compare the source and target org setup before deploying again.

Salesforce change set deployment QA checklist for admins

Use this checklist before uploading and deploying a Salesforce change set. It is written for editorial and admin review, so each item is specific to change set deployment rather than a generic release reminder.

• Confirm the article or release note explains whether the deployment starts in sandbox and ends in production, or uses another connected org path.
• Verify that the outbound change set section names the source org, target org, and component types included.
• Check that dependent metadata such as fields, layouts, permission sets, record types, flows, Apex tests, and custom labels are mentioned where relevant.
• Confirm that the inbound change set instructions include validation before deployment.
• Make sure the limitations section explains manual deployment, connected-org requirements, dependency checks, and the lack of version control.
• Review every official Salesforce link to ensure it points to change sets, deployment connections, inbound deployment, or best practices.

FAQs on Change Sets in Salesforce