Inbound Change Set
An Inbound Change Set is a Salesforce change set that arrives in the current org from a connected source org, awaiting deployment.
Definition
An Inbound Change Set is a Salesforce change set that arrives in the current org from a connected source org, awaiting deployment. Change sets are the legacy mechanism for moving metadata between connected orgs (sandbox to production, sandbox to sandbox). On the source side, an admin builds an Outbound Change Set listing the components to migrate; on the target side, the same change set appears as Inbound, where an admin reviews the contents and clicks Deploy to apply.
Inbound Change Sets sit in the target org's Setup > Deploy > Inbound Change Sets list until they are deployed or deleted. Each entry shows the source org, the change set name, the upload date, and the deployment status. The list is the target-side counterpart to Outbound Change Sets; together they form a paired deployment workflow that predates SFDX and is still supported in modern orgs. Many teams have moved to SFDX deployments because they offer source control and metadata API tooling, but change sets remain in use for small declarative deployments and orgs without dev-ops infrastructure.
How Inbound Change Sets deploy metadata
The change set deployment workflow
An admin in the source org creates an Outbound Change Set, adds components (objects, fields, classes, page layouts), specifies a target org, and uploads. The target org receives the change set as Inbound. A target-side admin opens it, reviews the contents (with optional dependency check), and clicks Deploy. The platform validates and deploys synchronously, reporting success or failure. Deployment is all-or-nothing per change set; partial deployments are not supported.
Deployment Connection prerequisite
Before any change set can flow, the source and target orgs must have a Deployment Connection. This is a two-sided trust: each org has a Deployment Connection record pointing to the other, both sides marked as Authorized. Without this, the Outbound Change Set has no upload target and the Inbound never appears. Configuring the connection is a one-time setup per org pair; subsequent change sets just use it.
Validating before deployment
The Validate action runs the deployment without committing changes. The platform compiles Apex, runs Apex tests if specified, and reports any errors. Validation should always precede the actual Deploy for production targets: production deployment requires 75% test coverage and at least one Apex test, and validation lets you catch coverage shortfalls before the deploy attempt is locked in.
Apex test requirements
Production deployments require Apex tests to pass. The change set deployment screen lets you select which tests to run: Run Default (tests in the change set), Run Local (all org tests), Run Specified (named tests), or Run All Tests. For most production deployments, Run Local is the standard choice. The platform requires 75% overall coverage and 1+ tests covering the deployed code; failures block the deploy.
Limits and componenting
Change sets cap at 10,000 components per set. Many metadata types are supported but some are not (Custom Settings data, certain managed package components, some UI configurations). The unsupported components must be deployed by other means (Data Loader for data, SFDX for some metadata, manual recreation for the rest). Plan the migration with the supported list in mind.
Rollback and the absence of
Change sets do not have built-in rollback. Once deployed, the metadata change is live. If the deployment introduces a regression, the only recourse is to deploy a corrective change set or manually undo through Setup. For high-stakes deployments, run validation in production, run tests in a Full Sandbox, and have a documented rollback plan involving a reverse change set or manual fixes.
Migration to SFDX and metadata API
Salesforce treats change sets as a legacy tool. New dev-ops teams use SFDX and the metadata API, which support source control, automated deployments, and CI/CD pipelines. Change sets remain for small declarative changes and teams without dev-ops infrastructure; for any team committed to source control or making frequent deployments, SFDX is the better path. Migration is a tooling project, not a Salesforce-mandated change.
Deploy an Inbound Change Set safely
Deploying an inbound change set is a target-side workflow. The steps below cover the validation and deployment path that minimizes production risk.
- Open Inbound Change Sets
Setup > Deploy > Inbound Change Sets. The list shows all received change sets with their source org and upload date.
- Select the change set
Click the change set name. The detail page lists every component in the set with type, name, and parent object.
- Review the components
Scan the list. Confirm every component is expected. Pay special attention to Profile and Permission Set changes; these affect security and are easy to deploy unintentionally.
- Run Validate
Click Validate. Choose the test option (typically Run Local Tests for production). The validation runs and reports any errors without committing.
- Fix any validation errors
If validation fails, work with the source-org admin to fix the underlying problem and upload a new change set. Do not try to deploy when validation fails.
- Run Deploy
After successful validation, click Deploy with the same test settings. The platform applies the change set; success is reported in the deployment status.
- Test in production immediately
Run smoke tests on the deployed features. The change set may have validated cleanly but still introduce regression on configurations not covered by tests.
Compile and test without committing. The recommended first step for production deploys.
Commit the change set. Use after successful validation.
Run only tests in the change set. Suitable for small isolated changes.
Run all tests in the org. Standard choice for production deployments.
Run a named subset of tests. Useful for targeted validation.
- Change sets cap at 10,000 components. Large migrations need to be split or moved to SFDX.
- Some metadata types are not supported. Custom Setting data, certain managed package components, and others must be deployed by other means.
- Production deployments require 75% Apex coverage. Change sets including new Apex without tests fail unless tests already exist in the target.
- No built-in rollback. Plan a reverse change set or manual procedure for high-stakes deployments.
- Deployment Connection must be Authorized on both sides. One-side authorization is not enough; the change set will not arrive.
Trust & references
Straight from the source - Salesforce's reference material on Inbound Change Set.
- Inbound Change SetsSalesforce Help
- Deploy a Change SetSalesforce Help
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. What is an Inbound Change Set?
Q2. When are change sets the right choice?
Q3. What's a more modern alternative to change sets?
Discussion
Loading discussion…