Deploy from Sandbox with Change Sets

Learning Objectives

After completing this unit, you’ll be able to:

  • Explain how change sets make deployment safer and easier.
  • Set up an organization to receive change sets.
  • Validate and deploy an inbound change set.

Deploy with Change Sets from Sandbox to Production

After you’ve created and tested changes in a safe environment, deploy the changes to your production org using change sets.

Diagram of inbound and outbound change sets between organizations


Your Trailhead Developer Edition org doesn’t contain change sets because change sets aren’t available in Developer Edition orgs. Change sets are available in some editions, including Enterprise and Unlimited. The following sections help you understand change sets so that you can learn how to use them in a supported edition.

Change sets make deploying changes easier.
  • Change sets represent sets of customizations in your org (or metadata components) that you can deploy to a connected org. Use change sets as a point-and-click tool to migrate your customizations.
  • There’s no need to download files to a local file system. Other deployment methods require you to work with local files.
  • The change set tool helps you discover and include dependent components. For example, a new custom field can’t be migrated if the custom object it belongs to doesn’t exist in the target org.
  • You define the set of components once. You can reuse the same set of components for another deployment by cloning the change set. Cloning change sets is helpful during the iterative phases of a project.

Deploying with change sets involves the following steps.

change set workflow


  • The first step is needed only once per org.
  • You can upload a change set from one sandbox to another sandbox, or from sandbox to production, and vice versa.
  • You can validate the change set as part of your review in the final step.

Authorize a Deployment Connection

Before you can receive change sets from a sandbox or other organization, authorize a deployment connection in the organization that receives the changes.

  1. Log into the organization that’ll receive inbound change sets. Usually this is the production organization associated with your sandbox.
  2. From Setup, enter Deployment in the Quick Find box, then select Deployment Settings.
  3. Click Edit next to the organization from which you want to receive outbound change sets. Usually this is your sandbox.
  4. Select Allow Inbound Changes and click Save.

Create and Upload an Outbound Change Set

Typically, you create an outbound change set in a sandbox organization and deploy it to production. But depending on your development lifecycle, you might choose to migrate changes in either direction between related organizations.
  1. From Setup, enter Outbound Change Sets in the Quick Find box, then select Outbound Change Sets.
  2. Click New.
  3. Enter a name for your change set and click Save.
  4. In the Change Set Components section, click Add.
  5. Choose the type of component (for example, Custom Object or Custom Field), the components you want to add, and click Add To Change Set.
    If you are experimenting with a test custom object and custom field, try adding just one of them to the change set first.
  6. Click View/Add Dependencies to see whether the components you’ve added to the change set are dependent on other customizations.
    In the case of the test custom object and custom field, the related component and page layout will both be listed.
  7. Select the dependent components you want to add and click Add To Change Set.
  8. Click Upload and choose your target organization.
    The outbound change set detail page displays a message and you get an email notification when the upload is complete.
Now log into the target organization, where you can see the inbound change set.

Validate an Inbound Change Set

Validating a change set lets you see the success or failure messages without committing the changes.
  1. From Setup, enter Inbound Change Sets in the Quick Find box, then select Inbound Change Sets.
  2. Click the name of a change set.
  3. Click Validate.

    We recommend starting a validation during off-peak usage time and limiting changes to your org while the validation is in progress. The validation process locks the resources that are being deployed. Changes you make to locked resources or items related to those resources while the validation is in progress can result in errors.



    If you change a field type from Master-Detail to Lookup or vice versa, the change isn’t supported when using the Validate option to test a deployment. This change isn’t supported for test deployments to avoid data loss or corruption. If a change that isn’t supported for test deployments is included in the deployment package, the test deployment fails and issues an error.

    If your deployment package changes a field type from Master-Detail to Lookup or vice versa, you can still validate the changes before you deploy to production. Perform a full deployment to another test sandbox. A full deployment includes a validation of the changes as part of the deployment process.

  4. After the validation completes, click View Results.
    If you receive error messages, resolve them before you deploy. The most common causes of errors are dependent components that aren’t included in the change set and Apex test failures.

Deploy an Inbound Change Set

Deploying a change set commits the changes it contains to the target organization.
  1. From Setup, enter Inbound Change Sets in the Quick Find box, then select Inbound Change Sets.
  2. In the Change Sets Awaiting Deployment list, click the name of the change set you want to deploy.
  3. Click Deploy.
    A change set is deployed in a single transaction. If the deployment is unable to complete for any reason, the entire transaction is rolled back. After a deployment completes successfully, all changes are committed to your org and the deployment can’t be rolled back.