How to Create and Deploy a Salesforce Change Set

Step by step: create an outbound change set, upload it, and deploy it as an inbound change set - plus the deployment connection you need between orgs before any of it works.

Updated 2026-09-09

A change set moves configuration - not data - from one org to a connected one, most commonly sandbox to production. It is Salesforce's original point-and-click deployment mechanism, and it still covers a large share of small, declarative changes.

The process has two sides: an outbound change set in the source org, and an inbound one that appears in the destination org once uploaded.

Before you start - the deployment connection

  • Setup → Deployment Settings, in both orgs, to establish which orgs can send change sets to which.
  • A sandbox can typically send to its production org and to other sandboxes on the same instance without extra setup once the org is created; a fresh connection is only needed for less common source-destination pairs.
  • Without this connection, the destination org will not appear as an option when you create the outbound change set.

Step 1 - create the outbound change set

  • In the source org: Setup → Outbound Change Sets → New.
  • Name it clearly - the name is what reviewers see on the inbound side, and "Change Set 4" tells the next person nothing.
  • Add components: each metadata type (custom fields, page layouts, flows, Apex classes, and so on) is added separately, and Salesforce prompts for dependencies it can detect - but not all of them.

Step 2 - upload it

Click Upload, choose the destination org, and confirm. The change set is now available for deployment on the destination side - uploading does not deploy it.

Step 3 - deploy the inbound change set

  • In the destination org: Setup → Inbound Change Sets, find the uploaded set.
  • Run Validate first if the option is available - it runs Apex tests and checks for missing dependencies without actually deploying.
  • Click Deploy, and address any component or test failure that comes back before retrying.

Common reasons a change set fails to deploy

  • A missing dependency - a formula field referencing a field that was not included in the set.
  • Insufficient Apex test coverage in the destination org (production requires at least 75% overall coverage for deployments that include Apex).
  • A component that already exists in the destination with conflicting configuration, most often a validation rule or a picklist value set that diverged between orgs.
  • The uploading user lacking the "Deploy Change Sets" or equivalent permission in the destination org.

Frequently asked questions

Can a change set move data, not just configuration?
No. Change sets move metadata only - object and field definitions, layouts, flows, Apex, and similar configuration. Records themselves need Data Loader, the Bulk API, or an ETL tool.
Can I edit a change set after uploading it?
Not the uploaded copy. You edit the outbound change set in the source org and upload it again, which creates a new version available on the destination side.
How is a change set different from a Metadata API or CLI deployment?
A change set is a point-and-click, org-to-org mechanism with no version control and no diff view beyond the component list. A Metadata API or CLI-based deployment (via the Salesforce CLI) works from a version-controlled project, supports code review, and can deploy to any org, not only ones with a change-set deployment connection.

More from the Admin How-To

Related reading