An inbound change set is the receiving side of a deployment. When a source org uploads an outbound change set to your org through a Deployment Connection, it appears in your Setup → Inbound Change Sets list, waiting to be deployed.
Where to find it
Setup → Environments → Change Sets → Inbound Change Sets.
The list shows every change set you’ve received, organised by source org, with status: Pending, Deployed, Failed.
What you can do with one
For each inbound change set, the actions available are:
- View — see the list of components, who sent it, when.
- Validate — runs a test deployment (parses metadata, checks dependencies, executes Apex tests at the selected test level). Doesn’t write changes.
- Deploy — actually commits the changes to your org.
- Quick Deploy — for an inbound change set you’ve validated successfully in the last 10 days, skip re-running tests and deploy immediately. Critical for production releases under change-window pressure.
- Delete — remove the change set from the list once it’s been deployed (or if it’s no longer needed).
The deployment options
When you click Deploy or Validate, you choose:
- Test level:
- No Test Run — skip tests (only allowed for non-production targets).
- Run Specified Tests — name the test classes that should run.
- Run Local Tests — run all Apex tests in the org (excluding managed-package tests). The default for production.
- Run All Tests in Org and Managed Packages — most thorough; rarely needed.
- Allow deployments of components when corresponding Apex tests are not in the org — usually off; turning it on lets you deploy without tests covering new code, which only works on sandboxes.
For production deployments, Run Local Tests is the standard choice; Salesforce enforces that the org must reach 75% Apex code coverage with all tests passing.
The validation deploy pattern
This is one of the most important production-deployment habits:
- Validate first, hours or days before the release window.
- Salesforce runs every test, reports coverage and failures.
- Fix any issues in the source sandbox, re-upload, re-validate.
- Once validation passes, you have 10 days in which to Quick Deploy — skipping tests because they already passed.
- During the change window, click Quick Deploy. Production update completes in minutes instead of an hour.
This decoupling means your high-risk change window doesn’t include waiting for tests. You’ve already verified them.
Failure modes
When a deploy fails, the inbound change set status shows Failed with an error log:
Test failure— one or more tests didn’t pass. The log names them.Code coverage— org-wide coverage dropped below 75% after the deploy.MissingDependency— a component the change set references doesn’t exist in the target (often a missing field added in source but forgotten in the change set).Duplicate value— something the change set creates already exists with the same name.Invalid metadata— version mismatch or unsupported component type.
The full failure log is downloadable from the change set detail page — essential for debugging.
Permissions to deploy
The user running the deploy needs:
- Deploy Change Sets permission (admin profile has it).
- Modify All Data (typically).
- Author Apex if Apex is in the change set.
When this matters
Inbound change sets are entirely passive on the source side; once uploaded, the source has done its job. The target admin owns the deployment from there. Coordinating who clicks Deploy, in which order, and when, is the heart of release management.
In one line
An inbound change set is what an uploaded outbound change set looks like from the target org’s side: a Pending bundle you Validate, then Deploy (or Quick Deploy) at your chosen time.
Verified against: Salesforce Help — Deploying a Change Set, Metadata API Developer Guide — Deploying, Salesforce DX Developer Guide. Last reviewed 2026-05-17 for Spring ‘26 release.