An outbound change set is a named bundle of metadata you assemble in the source org and send to a connected target org. It’s “outbound” from the source’s perspective; the same payload arrives in the target as an inbound change set.
Think of it as a parcel: you pack it in sandbox A, ship it to production B, and B’s admin opens and deploys it.
How it works
- In the source org (typically a sandbox), go to Setup → Outbound Change Sets.
- Click New, name the change set, give it a description.
- Add components — Apex classes, triggers, custom fields, layouts, flows, permission sets, etc. — using the standard component picker.
- (Highly recommended) Click View / Add Dependencies and add any related components Salesforce flags as required. Miss a dependency and the target deploy fails.
- (Optional) Add profiles that need updates — note that change sets handle profiles awkwardly (more on that below).
- Click Upload, pick the connected target org, and click Upload.
- The change set appears as an inbound change set in the target org.
- The target admin clicks Validate (test the deploy without committing) or Deploy.
Prerequisite: Deployment Connection
Outbound change sets only work between connected orgs. The orgs must:
- Belong to the same production-sandbox family (a Salesforce contract’s prod and its sandboxes).
- Have a Deployment Connection configured in Setup → Deployment Settings.
- Have the Allow Inbound Changes checkbox enabled on the target side.
You can’t send a change set between two unrelated production orgs, or between sandboxes that aren’t in the same family.
What change sets can and can’t carry
Change sets cover most common metadata, but not everything:
| Supported | Not supported |
|---|---|
| Apex classes, triggers, LWCs, Aura | Some standard list views and report filters |
| Custom objects and fields | Custom App Builder pages (varies by edition) |
| Flows, validation rules | Some user-level personalisations |
| Permission sets, profiles (with caveats) | Auto-numbers field initial values |
| Layouts, compact layouts, record types | Some sharing settings |
| Reports, dashboards (limited) | Most metadata-API-only types |
| Custom metadata types and records | Anything Salesforce hasn’t added to the change set surface |
When a component isn’t supported, you either:
- Manually configure it in the target post-deploy.
- Use Salesforce CLI / Metadata API instead.
The profile problem
Change sets handle profiles partially: only the bits of the profile that touch the specific components in the change set come along. If you change object permissions on Account for a profile, you have to add the Account object to the change set for the profile changes to ride along. Otherwise the profile arrives without those updates.
This is why most teams have stopped using change sets for profile/permission-set changes — too easy to miss something. Salesforce CLI handles this cleanly.
Once it’s uploaded
The change set in the source becomes read-only. You can’t edit it after upload. To make changes, you Clone it, modify, and re-upload — which creates a fresh inbound change set in the target.
When change sets still make sense
- Small admin-led teams without Git infrastructure.
- One-off, quick deploys between sandbox and production.
- Components that are well-supported by change set surface (no profile-edge-case nonsense).
When they don’t
- Anything requiring version control, branching, code review.
- Teams of more than two developers.
- Frequent / scheduled deploys.
- CI/CD pipelines.
For those, Salesforce CLI + Git is the modern path; commercial tools layer on top.
In one sentence
An outbound change set is a UI-built metadata bundle the source org sends to a connected target org for deployment.
Verified against: Salesforce Help — Change Sets, Metadata API Developer Guide, Salesforce DX Developer Guide. Last reviewed 2026-05-17 for Spring ‘26 release.