Outbound Change Set
An outbound change set is a collection of metadata components assembled in one Salesforce org so they can be sent to another connected org for deployment.
Definition
An outbound change set is a collection of metadata components assembled in one Salesforce org so they can be sent to another connected org for deployment. The org where you build and upload it is the source. The org that receives it is the target, where the same package shows up as an inbound change set ready to validate and deploy.
Admins create outbound change sets from Setup without writing code or installing tools. They are a declarative way to move customizations like custom fields, objects, Apex classes, and page layouts from a sandbox into production, or between any two orgs that share a deployment connection.
How outbound change sets move metadata between orgs
The source and target relationship
Every change set deployment involves two orgs joined by a deployment connection. The source org is where you make and test your changes, usually a sandbox. The target org is where you want those changes to live, often production. You build the outbound change set in the source, then upload it. When the upload finishes, the package appears in the target org as an inbound change set under the same name. This split keeps the two halves of a deployment clear. An outbound change set is the package leaving an org. An inbound change set is that exact package arriving in another org. They are two views of the same content, named identically, but managed from different screens. The person uploading from the sandbox and the person validating in production might even be different people on the team. For the two orgs to exchange change sets, an administrator first authorizes a deployment connection. A sandbox and its production org are connected automatically, but the receiving org must allow inbound change sets from the sending org before anything can be deployed.
Building and adding components
To start, go to Setup, type Outbound Change Sets in the Quick Find box, and open that page. Create a new change set with a name and an optional description, then click Add to pick components. You choose a component type, select the specific items you want, and add them to the set. You can return and add more components as long as the change set is still open. Change sets cover many configuration items but not everything. Custom objects, fields, validation rules, page layouts, Apex classes, triggers, Visualforce pages, and custom metadata types are all supported. Some items, like certain standard objects or specific settings, cannot travel in a change set and have to be recreated in the target org by hand. The Components Available in Change Sets reference in Salesforce Help lists what is and is not supported. Plan the contents before you build. A clear naming convention and a short description help the person who validates the inbound set later understand what each package is meant to do.
Dependencies are easy to miss
A component rarely stands alone. A custom field might sit on a custom object. An Apex class might reference a custom setting. If you add the field but forget the object, the deployment fails in the target org because the referenced piece is not there. Salesforce helps with this. On the change set detail page, click View/Add Dependencies to see the direct and indirect components your selections rely on. From there you can add the missing pieces in bulk. The best practice from Salesforce is plain: make sure each outbound change set contains every interdependent component that does not already exist in the target org. Dependencies are the most common reason a first deployment fails. A field formula that points at another field, a record type tied to a picklist value, a flow that calls an Apex class, all of these create links that must be satisfied. Walking the dependency view before every upload saves a round trip. It is cheaper to add a forgotten component now than to debug a failed validation and rebuild the set later.
Uploading freezes the change set
When the contents look complete, click Upload and choose the target org from the list of connected orgs. Uploading sends the package across the deployment connection. This step matters because an uploaded change set is locked. You cannot add, remove, or edit its components afterward. If you discover a missing component after uploading, you do not edit the original. Instead you clone the change set, add what was missing, and upload the clone. The first upload is effectively a snapshot. That immutability is a feature, since it guarantees the package that arrives in the target is exactly what was reviewed, with nothing changed in transit. After upload, the work shifts to the target org. There the package is an inbound change set. An admin in that org validates it, which is a check-only run that reports what would happen without committing anything, and then deploys it when ready. The outbound side of the process is finished once the upload succeeds.
Org locking and Apex tests
Change sets briefly lock an org during certain operations. The source org is locked while an outbound change set is validating, and the target org is locked while an inbound change set is deploying. During a lock you can still read and write your data. What you cannot do is make setup changes that would alter metadata, since that would shift the ground under an in-flight deployment. Apex tests come into play on the receiving side. When a change set containing Apex classes or triggers is deployed to a production org, Salesforce runs the local Apex tests by default. Production deployments must meet the platform code coverage requirement, so weak tests can block a deploy. If the target org is a sandbox instead, tests are not run automatically. Plan deployments for quieter periods because of the locking. Teams often schedule production change set deploys outside business hours so the short metadata freeze does not interrupt admins who need to make other configuration changes.
Where change sets fit, and where they do not
Outbound change sets shine for admin-led work between connected orgs. No command line, no Git repository, no extra installs. For a solo admin promoting a handful of fields and a validation rule from a sandbox to production, the point-and-click flow is hard to beat. The limits show up at scale. Change sets only move between connected orgs, so they cannot pull from or push to a version control system. They are a manual, one-at-a-time process with no built-in automation. They do not cover every metadata type, and they do not fit source-driven development where the repository is the single point of truth. For larger teams, Salesforce DX with unlocked or second-generation packages and a CI/CD pipeline gives version control, automated testing, and repeatable releases. The older Ant Migration Tool offers a file-based path through the Metadata API. Many orgs keep change sets for quick fixes while running DX for the main release pipeline. Choosing between them is about team size, release cadence, and how much automation the work justifies.
How to create and upload an outbound change set
Here is the outbound side of a change set deployment, from building the package in your sandbox to handing it off as an inbound change set in the target org. Do the work in the source org where your changes already exist and are tested.
- Open Outbound Change Sets
In the source org, go to Setup and type Outbound Change Sets in the Quick Find box. Select it, then click New to start a change set. Give it a clear name and a short description so reviewers know its purpose.
- Add your components
Click Add on the change set detail page. Pick a component type, select the specific items you want to deploy, and click Add to Change Set. Repeat for each type. The set stays editable until you upload it.
- Resolve dependencies
Click View/Add Dependencies to see direct and indirect components your selections rely on. Add any that do not already exist in the target org, then review the full list once more before uploading.
- Upload to the target org
Click Upload and choose the connected target org. Once the upload completes, the change set is locked and appears in the target as an inbound change set. Hand off to a target-org admin to validate and deploy.
A descriptive name and a one-line description that tell reviewers what the package contains and why it exists.
The metadata items you add by type, such as custom fields, Apex classes, page layouts, and custom metadata types.
The dependency tool that surfaces related components so the deployment does not fail on a missing reference.
The connected org you upload to, selected from the deployment connections that have authorized inbound change sets.
- An uploaded change set is locked. To fix a missing component, clone the set, add the piece, and upload the clone.
- The target org must authorize inbound change sets from your org first, or it will not appear as an upload destination.
- Deploying Apex to production runs local tests by default and must meet the code coverage requirement, so validate before the real deploy.
Prefer this walkthrough as its own page? How to Outbound Change Set in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Outbound Change SetsSalesforce
- Change Sets Best PracticesSalesforce
Straight from the source - Salesforce's reference material on Outbound Change Set.
- Select Components for an Outbound Change SetSalesforce
- Upload an Outbound Change SetSalesforce
Hands-on resources to go deeper on Outbound Change Set.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. After an Outbound Change Set is uploaded, how does it appear in the target org?
Q2. Between which orgs can an Outbound Change Set move metadata components?
Q3. Why might a release team still assemble an Outbound Change Set instead of using Salesforce DX?
Discussion
Loading discussion…