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.
