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.