How do you deploy an inbound change set in Salesforce?

In the target org Setup, go to Environments → Change Sets → Inbound Change Sets. Find the change set and click Deploy. You will be prompted to select options: run all tests, run specified tests, or run local tests only. After validation passes, the deployment proceeds. The deployment runs Apex tests and checks code coverage before applying the metadata changes. If tests fail or coverage drops below 75%, the deployment fails and nothing is committed.

What is the difference between validating and deploying a change set?

Validating a change set runs all the checks — test execution, code coverage validation, metadata conflict detection — without committing any changes to the org. It tells you whether the deployment would succeed. Deploying a change set runs the same checks and, if successful, commits all the metadata changes. Validation is recommended before deploying to production to catch issues without risk, and a successful validation can be used for a quick deploy within 10 days without running tests again.

When should you use change sets instead of Salesforce CLI?

Change sets make sense in specific scenarios: orgs without source control or developer tooling, simple one-off deployments between connected orgs where the component list is small and well-defined, and environments where the admin performing the deployment is not comfortable with CLI tooling. For any regular, repeatable deployment process, or for teams that need deployment history and rollback capability, Salesforce CLI with source control is the better approach.

Salesforce Jun 27, 2026 · Session 82

Salesforce Inbound Change Set: Receiving and Deploying Metadata

Q: What is an inbound change set in Salesforce?

An inbound change set is a collection of metadata components that has been uploaded from a source Salesforce org and is waiting to be deployed in the receiving org. The change set appears in the Inbound Change Sets list in Setup of the target org. Before it can be deployed, the receiving org admin must validate and then deploy the change set. Inbound change sets cannot be modified in the receiving org — they are received as packaged by the sending org.

Q: What components cannot be deployed via change set?

Several metadata types cannot be included in change sets: standard objects (you can include custom fields on standard objects, but not the objects themselves), users and their role assignments, queues, data records, email templates in certain categories, some reports and dashboards depending on org configuration, and person accounts. For metadata not supported by change sets, Salesforce CLI deployment or manual reconfiguration in the target org is required.

A change set is Salesforce's built-in mechanism for moving metadata between orgs that are connected in a deployment chain. An inbound change set is one that has been sent from a source org and is available for deployment in your current org.

Session 82 covers the receiving side: what an inbound change set contains, how to validate and deploy it, the deployment options available, and when change sets are still the appropriate tool despite the availability of Salesforce CLI.

What an inbound change set is

When another Salesforce org uploads a change set to your org (through an established deployment connection), it appears in your Inbound Change Sets list. This list is in Setup under Environments → Change Sets → Inbound Change Sets.

The change set contains a specific list of metadata components — Apex classes, custom objects, fields, layouts, flows, profiles, and any other metadata type the sending admin included. It also includes a description and optionally some notes from the sender.

You cannot modify what's in the change set once it's arrived in your org. If the sending org omitted a component you need, they must upload a new or updated change set. The inbound change set is read-only in the receiving org.

Validating before deploying

Before deploying to production, always validate. Validation runs the full deployment check — Apex test execution, code coverage calculation, metadata conflict detection — without committing any changes to the org. If validation fails, you see exactly what went wrong before any change has been applied.

To validate: in the Inbound Change Sets list, click the change set name to open its detail page, then click Validate. Select the test options (described below), then start the validation. The result appears in the deployment detail page when complete.

A successful validation creates a window of 10 days during which you can perform a Quick Deploy. Quick Deploy applies the validated change set to production without re-running all tests, significantly reducing deployment downtime in production environments where test suite execution is time-consuming.

Deployment test options

When deploying or validating a change set to a production org, Salesforce requires all Apex tests in the org to pass and overall code coverage to meet or exceed 75%. The test run options:

Default (Run Local Tests): Runs all tests in the org that are not part of installed managed packages. This is the standard for production deployments.
Run All Tests: Runs every test in the org including managed package tests. This is the most comprehensive but slowest option.
Run Specified Tests: Allows you to specify exactly which test classes to run. Useful for faster validation when you know which test classes cover the deployed components, but requires careful selection to ensure coverage is accurate.
No Test Run (sandbox only): Available only for sandbox deployments. Skips all test execution. Never appropriate for production.

Deploying the change set

After successful validation — or if you're deploying directly to a sandbox — click Deploy on the change set detail page. Choose your test run option. The deployment begins immediately and runs asynchronously.

Monitor the deployment in Setup → Environments → Deploy → Deployment Status. The status page shows: components deployed so far, components failed, tests passed, tests failed, and current code coverage percentage. If any test fails or coverage drops below 75%, the entire deployment fails atomically — no partial deployments, no half-applied changes.

When the deployment completes successfully, all components in the change set are live in the target org. There is no built-in rollback — if you need to reverse a change set deployment, you must manually identify the affected components and revert them, or deploy a new change set with the reversed changes.

Common deployment failures and causes

The most frequent inbound change set deployment failures:

Missing dependent components: The change set includes an Apex class that references a custom field that doesn't exist in the target org. The sending org should include all dependent components in the change set or deploy them first.
Test coverage below 75%: The change set introduces Apex code that is not covered by existing tests in the target org. New Apex in a change set requires either included test classes or pre-existing test coverage.
Active flow conflicts: A flow version in the change set conflicts with an active version in the target org. Deactivate the flow in the target org before deploying the new version via change set.
Required field not in change set: A custom object included in the change set has required fields not included in the deployment — the target org can't create the object structure without all required fields.

When change sets still make sense

Change sets are often described as an outdated deployment mechanism compared to Salesforce CLI and source control. This is partially true — for any team doing regular, repeatable deployments, CLI with a version-controlled project is substantially better. Change sets have no history, no rollback, no branching, and no ability to diff what's being deployed against what's already in the target org.

However, change sets remain appropriate in specific scenarios: smaller orgs without a technical team comfortable with CLI tooling, one-off deployments where setting up a full CLI project would take longer than the change set, and environments where the governance process requires an admin-to-admin handoff with explicit approval before deployment. In these contexts, change sets provide a simple, UI-based mechanism that doesn't require any local tooling setup.

FAQ

What is an inbound change set in Salesforce?

A collection of metadata components uploaded from a source org, waiting to be deployed in the receiving org. Appears in Setup → Environments → Change Sets → Inbound Change Sets. Cannot be modified in the receiving org — received as packaged by the sender.

How do you deploy an inbound change set?

Setup → Inbound Change Sets → click the change set → Deploy. Select test run option. Deployment runs asynchronously. Monitor at Environments → Deploy → Deployment Status. Fails atomically if tests fail or coverage drops below 75%.

What is the difference between validating and deploying?

Validation runs all checks without committing changes. Deployment commits changes on success. A successful validation creates a 10-day Quick Deploy window for faster production deployment without re-running tests.

When should you use change sets instead of CLI?

Change sets work for: orgs without CLI tooling, simple one-off deployments with small component lists, admin-to-admin handoffs requiring explicit approval. For regular, repeatable deployments needing history and rollback, use CLI with source control.

What components cannot be deployed via change set?

Standard objects, users and role assignments, queues, data records, some email templates, some reports and dashboards, and person accounts. Use CLI deployment or manual reconfiguration for unsupported metadata types.