11.1 Inbound & Outbound Change Sets

Inbound & Outbound Change Sets

Deploying customizations across a multi-tier Salesforce application lifecycle requires moving configuration and code seamlessly from lower environments (such as Developer or Partial Copy sandboxes) into staging environments (Full Copy sandboxes) and ultimately into Production. For declarative administrators and Platform App Builders, Change Sets represent the native, point-and-click deployment mechanism embedded directly within the Salesforce Setup user interface.

While programmatic developer teams frequently leverage the Salesforce CLI, Metadata API, and version control repositories, change sets remain a cornerstone topic on the Salesforce Platform App Builder certification exam. Candidates must understand how change sets establish connections, how components and dependencies are bundled, how deployments are validated and tested, and where change set architectural boundaries end.

---

Change Sets Architecture & Connected Organizations

Change sets are designed specifically for point-and-click metadata movement between affiliated Salesforce organizations. Unlike packaging solutions or file-based developer tools, change sets operate under a strict architectural constraint: deployments can only occur between organizations that share a direct deployment connection.

A deployment connection is an authorized pipeline between two orgs that belong to the same organizational ecosystem. Specifically:

• Sandbox to Production: Customizations authored in a development or staging sandbox can be deployed directly to the parent production organization.
• Production to Sandbox: Metadata residing in production can be deployed down to a connected sandbox (often used to back-port emergency production hotfixes).
• Sandbox to Sandbox: Customizations can be migrated between two sandboxes (e.g., from Developer Sandbox Dev1 to Staging Sandbox UAT), provided both sandboxes were provisioned from the exact same production organization.

---

Deployment Connections and Upload Authorization

Deployment connections are automatically established when a sandbox is provisioned from production. However, by default, these connections are dormant and unidirectional until explicitly authorized.

To transmit an Outbound Change Set from a source org to a target org:

1. An administrator must navigate to Setup > Deployment Settings in the target (receiving) organization.
2. The administrator locates the connection representing the source sending organization.
3. The administrator clicks Edit and selects the checkbox labeled Allow Inbound Changes.

If Allow Inbound Changes is not enabled in the target organization, the source organization's administrators will not see the target org listed in the dropdown menu when attempting to upload an outbound change set.

[Source Sandbox (Dev)]  ---- Upload Attempt ---->  [Target Org (UAT or Prod)]
                                                         |
                                             Deployment Settings
                                           "Allow Inbound Changes" = TRUE?
                                           ├── YES: Change set uploads successfully
                                           └── NO:  Target org hidden from upload list

---

Outbound Change Sets: Packaging & Immutability Rules

An Outbound Change Set is created in the source organization to assemble the metadata components intended for migration.

The Outbound Lifecycle

1. Creation: The app builder navigates to Setup > Outbound Change Sets, clicks New, and provides a descriptive name and description (e.g., Release_2026_Q4_Case_Routing_v1.0).
2. Component Selection: The app builder selects metadata components across dozens of supported types, including Custom Fields, Custom Objects, Record-Triggered Flows, Validation Rules, Lightning Pages, and Permission Sets.
3. Adding Dependencies: The app builder uses the View/Add Dependencies button to identify and attach supporting metadata required by the selected components.
4. Upload: The app builder selects the target destination org from the authorized deployment connections list and clicks Upload.

The Immutability Rule

Once an administrator clicks Upload, the outbound change set enters an immutable, locked state.

• You cannot add new components to an uploaded change set.
• You cannot remove components from an uploaded change set.
• You cannot modify existing components within the uploaded change set.

If you discover that an essential custom field, formula, or email template was omitted, or if a component contains an error, you cannot edit the uploaded change set. Instead, you must locate the change set in the source organization, click Clone, assign a new name (e.g., Release_2026_Q4_Case_Routing_v1.1), add or adjust the missing components, and upload the newly cloned change set.

---

Inbound Change Sets: Validation, Quick Deploy & Deployment

When an outbound change set completes its upload, it appears in the target organization under Setup > Inbound Change Sets with a status of Awaiting Deployment. Inbound change sets do not alter target org metadata simply by arriving; they require deliberate administrative action.

Validate vs. Deploy

Administrators have two primary actions when working with an inbound change set:

1. Validate (Dry-Run Simulation):

   • Executes a simulated deployment without committing any metadata changes to the target database.
   • Checks for missing dependencies, syntax errors, profile mismatches, and executes Apex unit tests according to the selected test level.
   • Produces a detailed deployment log highlighting exact failure reasons if errors occur.
   • Best Practice: Always validate change sets during staging or pre-deployment windows prior to off-hours production deployment.

2. Deploy:

   • Executes the deployment and, upon successful completion, permanently writes the metadata changes into the target organization.
   • Executes as an atomic transaction: if a single component fails or a single Apex unit test fails to meet required thresholds, the entire deployment fails and rolls back.

Quick Deploy Capability

Running extensive Apex test suites during production deployment windows can consume hours. Salesforce provides Quick Deploy to accelerate production release cutovers:

• If an inbound change set is successfully validated within the last 10 days, and
• The validation ran successful Apex tests with the applicable coverage requirements, and no intervening deployment invalidated eligibility,
• An administrator can click Quick Deploy in the target org to commit the metadata immediately without re-executing unit tests.

---

Apex Test Execution Options in Deployment

When deploying metadata to production (or validating an inbound change set), Salesforce enforces Apex testing requirements to safeguard system stability. The deployment wizard presents four distinct test execution levels:

                    [Inbound Change Set Test Options]
                                   |
        ┌──────────────────────────┼──────────────────────────┐
        ▼                          ▼                          ▼
   [Default]               [Run Local Tests]        [Run Specified Tests]
  Sandbox: 0 tests        All org unit tests         Only targeted test
  Prod: All local if      (ignores managed           classes executed
  Apex present            packages)                  (ideal for hotfixes)

---

Fundamental Change Set Limitations

Understanding what change sets cannot do is critical for both the App Builder exam and day-to-day enterprise releases:

1. No Destructive Changes (Cannot Delete Metadata):
   • Change sets can create new components and update existing components. They cannot delete components from the target organization.
   • If a custom field, validation rule, or Apex class is retired, an administrator must either manually delete it in the target organization or execute a destructive deployment using the Salesforce CLI or Metadata API (destructiveChanges.xml).
2. No Automated Rollback Functionality:
   • If a change set deployment encounters an error during execution, the transaction aborts atomically, leaving the target org untouched.
   • However, once a change set successfully deploys, there is no "Rollback" or "Undo" button. To revert changes, an administrator must manually undo configurations or deploy a counter-change set that restores prior definitions.
3. Metadata Only, Zero Record Data:
   • Change sets migrate metadata schemas, not data records. They do not migrate Account, Contact, Opportunity, or Custom Object data records. Record data must be loaded using the Data Import Wizard, Data Loader, or Salesforce CLI.
4. No Version Control Integration:
   • Change sets do not integrate natively with Git repositories or track historical diffs between iterations.

Official Source Check

Checked October 19, 2026: Quick deployment requirements and Apex coverage.