Outbound Change Set
A change set created in a Salesforce org (typically a sandbox) to send metadata components to another connected org (typically production), containing customizations like fields, objects, and classes for deployment.
Definition
A change set created in a Salesforce org (typically a sandbox) to send metadata components to another connected org (typically production), containing customizations like fields, objects, and classes for deployment.
In plain English
“An Outbound Change Set is a change set created in a Salesforce org (typically a sandbox) to send metadata components to another connected org (typically production). It contains the customizations like fields, objects, and Apex classes you want to deploy.”
Worked example
The release engineer at Cobblepath Marketing assembles an Outbound Change Set in the company's full-copy sandbox containing 24 metadata components - six new custom fields, two Apex classes, a Lightning page, four flow versions, and 11 picklist value updates - destined for production. She uploads the set to the connected production org, where it appears as an Inbound Change Set; the production admin reviews the components, runs Apex tests, and clicks Deploy. The Outbound Change Set is the legacy alternative to source-format SFDX deploys; for Cobblepath's older release pipeline, it's still the documented path until they migrate to a Git-based deploy model.
Why Outbound Change Set matters
An Outbound Change Set is a change set created in a Salesforce org (typically a sandbox) to send metadata components to another connected org (typically production), containing customizations like fields, objects, classes, and other deployable items. The source org is where the changes were made, and the change set is the package being prepared for deployment to the target org. After the outbound change set is uploaded, it appears in the target org as an inbound change set ready for validation and deployment.
Outbound change sets are one mechanism for moving customizations between connected orgs. They're declarative, accessible to admins, and don't require developer tooling. However, change sets have limitations: they only work between connected orgs (no Git workflow), they can't include all metadata types, they don't support modern source-driven development, and they're a manual process rather than automated. Modern Salesforce DX with packages and CI/CD is more powerful but requires more setup. Change sets remain useful for simpler scenarios.
How organizations use Outbound Change Set
Uses outbound change sets for routine sandbox-to-production deployments where the metadata is straightforward.
Helps clients evaluate when change sets are sufficient versus when they need Salesforce DX.
Uses change sets for admin-led deployments and Salesforce DX for developer-led deployments.
Trust & references
Straight from the source - Salesforce's reference material on Outbound Change Set.
- Outbound Change SetsSalesforce Help
- Upload an Outbound Change SetSalesforce Help
Test your knowledge
Q1. What is an Outbound Change Set?
Q2. What's the relationship to inbound change sets?
Q3. When are change sets the right choice?
Discussion
Loading discussion…