Inbound Change Set
An Inbound Change Set is a change set that has arrived in the Salesforce org you are logged into.
Definition
An Inbound Change Set is a change set that has arrived in the Salesforce org you are logged into. Another org uploaded it over a shared deployment connection. It is the receiving half of a two-sided workflow. An admin builds an Outbound Change Set in a sandbox and uploads it, and the same bundle shows up in the target org.
You cannot edit one. Its contents are fixed the moment the source admin uploads it, so a change of mind means building and uploading a new set. Deployment is all or nothing: every component commits together, or none of them do.
Change sets remain supported and are not on Salesforce's retirement list as of Summer '26. Salesforce does steer release-heavy teams toward DevOps Center, the Salesforce CLI, and DX Inspector. They carry no source control, and once a deployment succeeds there is no rollback.
In plain English
“Imagine a coworker packs a sealed box and mails it to your office. You can read the shipping list, but you cannot add anything or take anything out. When you accept it, everything inside gets unpacked at the same moment. If one item is broken, the whole delivery bounces back.”
Worked example
A release admin at a logistics company opens Setup and types Inbound Change Sets in the Quick Find box. Waiting there is a set named REL-2026-08-Freight, uploaded from the UAT sandbox two hours earlier. It holds 41 components: the Freight_Quote__c custom object, four fields including Fuel_Surcharge__c, a page layout, the FreightQuoteCalculator Apex class, and its test class. She clicks Validate and picks Run Local Tests. Twelve minutes later the results show 78% org-wide coverage and zero failures. Because the validation is fresh, the set qualifies for a quick deployment, so she runs it from Deployment Status without paying for tests twice. The page reports Succeeded and Fuel_Surcharge__c is live.
What the receiving org can and cannot do
The deployment connection has to be authorized first
Nothing arrives unless the target org agreed to it first. Deployment connections only exist between orgs affiliated with the same production org, so two unrelated companies cannot be wired together. The switch lives in the receiving org: Setup, Quick Find, Deployment Settings, then Edit next to the source org and Allow Inbound Changes. Authorization is directional on purpose, so you can enforce a promotion path where UAT uploads to production but production cannot upload back. Most reports of a change set vanishing in transit turn out to be this checkbox.
Validate first, and the 10-day window it buys you
Validate runs the entire deployment against the target without committing anything. Apex compiles, tests execute, and you get the same success or failure messages a real deploy would produce. It also earns you something concrete. If a validation succeeded within the last 10 days, with tests passed and coverage held, the set qualifies for a quick deployment. That second run skips the tests entirely. On an org where local tests take 90 minutes, that is the difference between a maintenance window and a coffee break. Validation locks the metadata it touches, so run it off-peak.
Test levels and where the 75% bar actually sits
Deploying to production automatically runs all local Apex tests when the set contains Apex classes or triggers. Sandbox deployments skip tests unless you ask. The threshold then moves depending on how tests were chosen. Run all org tests or all local tests and you need 75% overall, with some coverage on every trigger. Run only specified tests and each deployed class and trigger has to clear 75% on its own. That second rule quietly punishes anyone who cherry-picks one fast test class to shorten the window.
One transaction, and no undo afterwards
A deployment is a single transaction. If any component fails, everything reverts and the org is untouched, which is the sensible half of the design. The other half shows up on success: once changes commit, there is no rollback button. Your remedies are a corrective change set or manual repair in Setup. Change sets also cannot delete or rename components. Removal means using the target org's own UI, and a rename is a delete there followed by a fresh upload.
What will not fit in the box
A change set caps at 10,000 files, and teams that hit it are usually dragging every report and dashboard along for the ride. Salesforce's own advice is to split those into separate sets. Coverage is uneven in other ways too. Private reports in the My Personal Custom Reports folder never appear in the picker. Unfiled public reports fail to deploy even when you add them, and some components travel only as dependencies. Record data is not metadata at all, so rows need a different tool.
The release history you do not get
A change set records no version and no diff, and it has no concept of a branch. Six months after a release, nothing in the target org tells you which set introduced a given field. Nothing records what the configuration looked like beforehand either. Rebuilding that story means reading Setup Audit Trail entries and old release notes, which is the exact work source control exists to remove. That is the honest case against change sets, and it has nothing to do with whether Salesforce still supports them.
How to deploy an inbound change set
You need deploy permission in the target org, and the source org must be authorized before anything shows up. Budget real time for validation.
- Authorize inbound changes
In the receiving org, go to Setup and enter Deployment Settings in the Quick Find box. Click Edit next to the source org, select Allow Inbound Changes, and save.
- Open the inbound list
From Setup, enter Inbound Change Sets in the Quick Find box and select Inbound Change Sets. Uploaded sets appear with their source org, upload date, and description.
- Read the component list before touching anything
Click the change set name and review every component. This is your only review point, because an inbound set cannot be edited or deployed piece by piece.
- Validate and read the results
Click Validate, choose a test level, and wait. When it finishes, click View Results and confirm zero failures plus enough coverage. Run this outside business hours.
- Deploy, then confirm on Deployment Status
Click Deploy. From Setup, enter Deployment in the Quick Find box and select Deployment Status. It shows the run in progress and the last 30 days of history.
Runs the full deployment without committing anything. Treat it as mandatory for any production target.
Commits every component at once. There is no rollback after it succeeds.
Offered from Deployment Status when a validation from the last 10 days still qualifies.
- A set can go unavailable without warning after it expires, after the source admin deletes it, or after the source sandbox is refreshed. The inbound list lags behind all three.
- Two admins validating sets that touch the same metadata will collide, because the first one holds the lock.
- Apex jobs referencing a component can block the deploy, unless Deployment Settings in the target org allows deployments while those jobs are pending.
Prefer this walkthrough as its own page? How to Inbound Change Set in Salesforce, step by step
How organizations use Inbound Change Set
Moves a quarterly release of page layouts, validation rules, and two Apex classes from a Full Sandbox to production, validating Friday and quick-deploying Sunday night.
Has no source control and one admin, so change sets are the entire release process: build in a Developer Sandbox, upload, validate, deploy.
Ships a scoped configuration into a client org over an authorized deployment connection, leaving the client's own team as the only people who click Deploy.
Trust & references
Cross-checked against the following references.
- Inbound Change Sets (opens in new tab)Salesforce
- When Change Sets Become Unavailable (opens in new tab)Salesforce
- Change Sets Best Practices (opens in new tab)Salesforce
- Deployment Connections for Change Sets (opens in new tab)Salesforce
- Running Tests in a Deployment (opens in new tab)Salesforce
- deployRecentValidation() (opens in new tab)Salesforce
- Components Available in Change Sets (opens in new tab)Salesforce
- Deploy Using Change Sets (opens in new tab)Salesforce
Straight from the source - Salesforce's reference material on Inbound Change Set.
- Deploy a Change Set (opens in new tab)Salesforce
- Validate a Change Set (opens in new tab)Salesforce
- Monitor Deployments (opens in new tab)Salesforce
Hands-on resources to go deeper on Inbound 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 writes and edits salesforcedictionary.com, published by KineticBit Inc., to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
+5 pts / dayQ1. What can an admin actually do with an inbound change set in the target org?
Q2. A validation of your change set succeeded eight days ago, tests passed, and coverage was met. What does that buy you?
Q3. Your release has to remove an obsolete custom field from production. How do change sets handle it?
Discussion
Loading discussion…