Outbound and Inbound Change Sets and Deployment Connections

Why This Topic Matters

Every serious Salesforce implementation follows a simple rule: build and test in a sandbox, then promote to production. The Advanced Administrator exam tests whether you understand the native, point-and-click mechanism Salesforce provides for that promotion: change sets, supported by deployment connections. In the Environment Management and Deployment section of the exam, you are expected to know which tool fits which scenario, who must do what in which org, what change sets can and cannot carry, and how to troubleshoot a failed or blocked deployment. Questions in this area are scenario-based and often hinge on one small detail, such as whether two orgs are related, or in which org a connection must be authorized. Mastering the mechanics therefore translates directly into exam points, and into fewer broken production deployments in real life.

What Change Sets Are

A change set is a container of metadata (customizations) that you move from one Salesforce org to another. Metadata includes things like custom objects, custom fields, page layouts, validation rules, flows, Apex classes, Lightning pages, reports, dashboards, permission sets, and many other configuration components. A change set never moves records (data). If you need to move Accounts or Contacts, you use Data Loader, Data Import Wizard, or another data tool, not a change set.

There are two sides to every change set:

Outbound Change Set - Created in the source org (usually a sandbox). You add components, optionally add profile or permission set settings, and then upload it to a connected target org.

Inbound Change Set - Received in the target org (usually production or another sandbox). You can validate it, deploy it, or delete it. The same change set is outbound in one org and inbound in the other.

A critical limitation: change sets only work between related orgs, meaning a production org and the sandboxes created from it. You cannot send a change set from one company's production org to an unrelated production org, or from a Developer Edition org to a production org. For unrelated orgs you must use unmanaged packages, the Metadata API, Salesforce CLI, or a similar tool.

What Deployment Connections Are

A deployment connection is the authorization that allows one org to send change sets to another. Salesforce automatically creates deployment connections between a production org and all of its sandboxes, and between those sandboxes, but no changes are allowed until a connection is explicitly authorized.

The rule that the exam loves: authorization is granted in the target (receiving) org. In the org that will receive changes, go to Setup, search for Deployment Settings, click Edit next to the source org, and select Allow Inbound Changes. Authorization is directional. Allowing sandbox A to send changes to production does not allow production to send changes to sandbox A; that would require a separate authorization performed in sandbox A.

Two more useful facts about connections:

1. A newly created or refreshed sandbox needs its deployment connection to be re-authorized if you want to deploy into it or from it in a new direction, because the authorization is tied to the org.
2. Deployment Settings is where you also control whether flows and processes are deployed as active, which requires a flow test coverage percentage to be met.

How the Process Works End to End

Step 1 - Authorize the connection. In the target org, open Deployment Settings and check Allow Inbound Changes for the source org.

Step 2 - Build the outbound change set in the source org. Go to Setup, search for Outbound Change Sets, click New, name it, and add components. Use View/Add Dependencies to automatically pull in components the selected ones depend on, such as a custom field that a validation rule references. If you want field-level security and object permissions for the new components to come along, add the relevant profiles or permission sets. Profile settings are only included for components that are also in the change set; a profile in a change set is not a full copy of the profile.

Step 3 - Upload. Choose the target org and click Upload. Once uploaded, the outbound change set is locked and cannot be edited. If you forgot something, clone the change set, add the missing components, and upload again. Uploading can take a few minutes to appear in the target; you receive an email when it arrives.

Step 4 - Validate in the target org. Go to Setup, search for Inbound Change Sets, open the change set, and click Validate. Validation runs the deployment without committing anything, so you can see errors, Apex test results, and code coverage before touching production. This is the safest first move and is often the correct answer to questions about reducing risk.

Step 5 - Deploy. Click Deploy, choose a test level if deploying to production (Default, Run Local Tests, Run All Tests, or Run Specified Tests), and confirm. Deployments to production require Apex tests to pass with at least 75% overall code coverage and no failing tests when Apex is involved. If you validated successfully and the validation is still recent, you can use Quick Deploy to deploy without re-running tests. Deployment is all or nothing: if any component fails, nothing is committed.

Step 6 - Monitor. Use the Deployment Status page to watch progress, review errors, and see component-level results. Failed deployments typically fail because of missing dependencies, differing API versions, missing fields referenced by layouts, or test failures.

Key Limits and Restrictions to Memorize

Change sets cannot delete components in the target org. They only add new components or overwrite existing ones. Deletions and renames must be done manually in the target or via another tool.

Change sets cannot move data.

Change sets cannot be used between unrelated orgs.

Not every component type is supported. Examples that historically are not supported include some org-wide settings, certain console configurations, Case team roles, and various administrative settings; these must be recreated manually. If a question describes a setting that is not a true metadata component, suspect it is not deployable via change set.

A change set can contain up to 10,000 files with a total size limit (roughly 400 MB uncompressed). Larger deployments should be split or moved with the Metadata API.

Uploaded change sets remain available in the target org for a limited time (about six months) before expiring.

Flows deploy as inactive by default unless the Deployment Settings option to deploy processes and flows as active is enabled and flow coverage requirements are met.

Required permissions: Create and Upload Change Sets for the source side, and Deploy Change Sets for the target side. Deploying Apex also requires Author Apex. In production, Author Apex is granted but Apex code itself cannot be edited directly, which is one reason change sets exist.

How Change Sets Compare to Alternatives

Change Sets - Declarative, no tooling required, related orgs only, no deletions.
Unmanaged Packages - Work between unrelated orgs, good for one-time distribution, components become editable in the target.
Metadata API / Salesforce CLI / Ant Migration Tool - Scriptable, supports destructive changes (deletions), works between any orgs, requires technical setup.
DevOps Center - Salesforce's newer point-and-click, source-control-backed alternative that supports work items and pipelines.

The exam expects you to pick change sets when the scenario describes an admin moving configuration from a sandbox to its production org without developer tooling, and to pick an alternative when the scenario involves unrelated orgs, deletions, automation, or version control.

Exam Tips: Answering Questions on Outbound and Inbound Change Sets and Deployment Connections

Tip 1 - Spot the direction words. Outbound always means the sending org where you build and upload. Inbound always means the receiving org where you validate and deploy. If a question asks where the admin should click Deploy, the answer is the target org's Inbound Change Sets page.

Tip 2 - Authorization happens in the receiver. If a sandbox admin cannot see production as an available target when uploading, the fix is to log in to production, open Deployment Settings, and select Allow Inbound Changes for that sandbox. Any answer that says to authorize in the sending org is wrong.

Tip 3 - Related versus unrelated. Read whether the orgs share a sandbox-production relationship. A Developer Edition org, a partner's org, or another company's production org is unrelated, and change sets are not an option. Choose unmanaged packages or Metadata API tools instead.

Tip 4 - Data is never deployed. If the scenario mentions records, test accounts, or sample data, eliminate change sets immediately and look for Data Loader or a sandbox template answer.

Tip 5 - No deletions. If a requirement is to remove a field or delete a component in production, a change set cannot do it. The answer will involve manual deletion or destructive changes via Metadata API or CLI.

Tip 6 - Locked after upload, so clone. If an admin uploaded a change set and realizes a component is missing, the correct action is to clone the change set, add the component, and upload the clone. You cannot edit an uploaded change set.

Tip 7 - Validate first for safety. When a question emphasizes minimizing risk, avoiding downtime, or checking for errors before making changes in production, the answer is to Validate the inbound change set, then use Quick Deploy once validation passes.

Tip 8 - Dependencies cause most failures. If a deployment fails with a message about a missing field, object, or class, the fix is to add the dependent component, often by using View/Add Dependencies, and upload again. Do not jump to answers about profiles or permissions unless the error is about access.

Tip 9 - Profiles and permission sets carry access only for included components. If users in production cannot see new fields after deployment, the likely cause is that field-level security was not included because the profile or permission set was not added to the change set. Adding the permission set to the change set, or setting FLS manually in production, is the remedy.

Tip 10 - Know the Apex rules. Production deployments containing Apex require 75% code coverage and passing tests. Sandbox-to-sandbox deployments do not enforce the coverage requirement. If a question mentions a coverage failure, the fix is to improve tests in the sandbox and redeploy, not to lower a setting in production.

Tip 11 - Flows arrive inactive. If a deployed flow is not running in production, remember flows deploy as inactive by default. Either activate it manually or enable the Deployment Settings option to deploy flows as active.

Tip 12 - Watch for permission-based distractors. An admin who cannot create an outbound change set needs Create and Upload Change Sets; an admin who cannot deploy needs Deploy Change Sets. System Administrator profiles have both, but a custom admin profile may not.

Tip 13 - Refreshed sandboxes reset expectations. After a sandbox refresh, pending inbound change sets in that sandbox are gone and deployment connections may need to be re-authorized. If a question involves a recently refreshed sandbox and a missing connection, re-authorization in Deployment Settings is the answer.

Tip 14 - Eliminate by capability. When several tools appear as options, ask three questions: Are the orgs related? Does anything need to be deleted? Is automation or version control required? Any yes to the last two, or a no to the first, points away from change sets.

Quick Review Summary

Change sets move metadata, not data, between related orgs. Build and upload the outbound change set in the source org; validate and deploy the inbound change set in the target org. Deployment connections are authorized in the receiving org via Deployment Settings with Allow Inbound Changes, and authorization is one-directional. Uploaded change sets are locked, so clone to modify. Change sets cannot delete components, are all-or-nothing, and require 75% Apex coverage for production. Use View/Add Dependencies to avoid failures, include permission sets or profiles to carry field-level security, validate before deploying, and monitor results on the Deployment Status page. Keep these rules in mind and change set questions on the exam become straightforward.