Study guide
11.1 Inbound & Outbound Change Sets
Salesforce Certified Platform App Builder Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Platform Architecture, Boundaries & Extensions
1.1 Declarative vs. Programmatic Architecture & Limits 1.2 AppExchange Solutions & Package Selection 1.3 Core CRM Standard Objects & Capabilities
2 Chapter 2: Security, Access & Analytics
2.1 Object-Level & Field-Level Security 2.2 Record-Level Sharing Architecture 2.3 Advanced Sharing & Scoping Solutions 2.4 Reports, Custom Report Types & Dynamic Dashboards
3 Chapter 3: Data Model Architecture & Relationships
3.1 Custom Objects & Custom Field Types 3.2 Master-Detail & Lookup Relationships 3.3 Many-to-Many Relationships & Junction Objects 3.4 Schema Builder & Data Architecture Visualization
4 Chapter 4: Data Management & External Integrations
4.1 Field Type Conversions & Data Loss Considerations 4.2 Data Import Wizard vs. Data Loader 4.3 Salesforce Connect, External Objects & Indirect Lookups
5 Chapter 5: Declarative Formulas & Validation Rules
5.1 Cross-Object Formulas & Advanced Formula Functions 5.2 Roll-Up Summary Fields & Calculation Rules 5.3 Validation Rules & Error Handling Strategies
6 Chapter 6: Salesforce Flow Architecture & Design
6.1 Flow Fundamentals & Flow Trigger Types 6.2 Record-Triggered Flows: Fast Field Updates vs. Actions 6.3 Screen Flows & Guided User Interactions 6.4 Flow Execution Architecture, Bulkification & Fault Paths
7 Chapter 7: Complex Automation & Approval Processes
7.1 Multi-Step Approval Processes & Approver Routing 7.2 Approval Actions, Rejections & Record Locking 7.3 Automation Selection Strategy & Legacy Migration Patterns
8 Chapter 8: Lightning App Builder & Page Customization
8.1 Lightning Record, Home & App Pages 8.2 Standard, Custom & AppExchange Lightning Components 8.3 Custom Buttons, Web Links & Quick Actions
9 Chapter 9: Dynamic UI, Record Types & Mobile Experience
9.1 Dynamic Forms & Conditional Component Visibility 9.2 Dynamic Actions & Page Interaction Patterns 9.3 Record Types, Business Processes & Picklist Control 9.4 Salesforce Mobile App Customization & Compact Layouts
10 Chapter 10: Application Lifecycle Management & Sandboxes
10.1 Application Lifecycle Management (ALM) Stages & Governance 10.2 Sandbox Types, Capacity & Refresh Cycles 10.3 Sandbox Strategy for Development, Testing & Training
11 Chapter 11: Deployment Tools & Packaging Strategies
11.1 Inbound & Outbound Change Sets 11.2 Change Set Dependency Tracking & Deployment Sequencing 11.3 Managed vs. Unmanaged Packages & Distribution
12 Current Exam Blueprint, Agentforce & Flow Operations
12.1 Current Exam Facts, Official Weights & Study Mapping 12.2 AgentExchange: Extending an Org with the Agentforce Marketplace 12.3 Agentforce Automation for App Builders 12.4 Flow Approval Processes, Monitoring & Troubleshooting
11.1 Inbound & Outbound Change Sets
Key Takeaways Explain This Topic AI
Change sets provide point-and-click declarative metadata deployment strictly between affiliated Salesforce organizations connected to the same production instance.
A deployment connection must be established, and the target receiving organization must explicitly enable 'Allow Inbound Changes' before an outbound change set can be transmitted.
Once an outbound change set is uploaded, it is permanently locked and immutable; any modifications require cloning the change set or creating a new version.
Inbound change sets support validation (dry-run simulation) and deployment, offering four test levels: Default, Run Local Tests, Run All Tests, and Run Specified Tests.
Change sets cannot execute destructive changes (deletions) and do not support automated rollback; failed deployments roll back automatically, but successful deployments require manual remediation to reverse.
Last updated: October 2026
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.
Important
Affiliated Orgs Only: Change sets cannot deploy metadata between unrelated organizations. You cannot use change sets to transfer configuration between two distinct production orgs, between Developer Edition orgs, or between a Trailhead Playground and a sandbox. Moving metadata across unrelated organizations requires unmanaged/managed packages, Salesforce CLI, or Metadata API migrations.
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:
An administrator must navigate to Setup > Deployment Settings in the target (receiving) organization .
The administrator locates the connection representing the source sending organization.
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
Note
Sandbox Refresh Impact on Connections: When a sandbox is refreshed from production, all existing deployment connections are reset to their default state. Administrators must re-enable Allow Inbound Changes in any sandbox or production org that needs to receive inbound change sets following a refresh cycle.
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
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 ).
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.
Adding Dependencies: The app builder uses the View/Add Dependencies button to identify and attach supporting metadata required by the selected components.
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:
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.
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.
Tip
Optimizing Maintenance Windows: Validate your production change set on Friday afternoon using Run Local Tests . Review the validation results to ensure 100% success. During the scheduled Saturday night release window, use Quick Deploy to skip rerunning tests, reducing deployment time; duration and service impact still depend on the release and avoiding late-night test run delays.
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:
Test Level Option Scope of Tests Executed Production Requirements Ideal Use Case
Default In Sandboxes: No tests run. In Production: If change set contains Apex, all local tests run; if no Apex, no tests run. Requires 75% overall Apex code coverage if Apex components are included. Sandbox-to-sandbox migrations or purely declarative production releases without Apex.
Run Local Tests Runs all Apex unit tests created in the target org, excluding tests originating from installed managed packages. Requires 75% overall coverage across all local classes, plus some coverage on every trigger. Standard major production releases and quarterly milestone deployments containing Apex code.
Run All Tests Runs every Apex test in the target org, including local tests AND tests inside installed managed packages. Requires 75% overall coverage. Managed package test failures can block deployment. Comprehensive system audits; rarely recommended for routine production deployments.
Run Specified Tests Runs ONLY the specific test classes explicitly listed by the administrator (entered as a comma-separated list). Every specified test class must pass; each deployed Apex class and trigger must achieve at least 75% coverage individually. Emergency production hotfixes and minor bug fixes to avoid running thousands of unrelated tests. [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:
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 ).
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.
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.
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 .