Salesforce Change Sets: Complete Guide
Quick Summary:
Change sets move metadata (fields, flows, layouts, code) between connected Salesforce orgs -- typically from a sandbox to production -- without touching actual record data.
What Is a Change Set?
A change set is a bundle of metadata components packaged together for deployment from one org to a directly connected org. This is the standard, point-and-click way to move configuration built and tested in a sandbox into production, without manually rebuilding every field, flow, and layout by hand.
⚠️ Before You Start
Change sets only move metadata, never data. If your change involves both configuration and specific records (like a new picklist value that certain existing records need updated to use), the data portion needs a separate tool like Data Loader.
How to Create and Deploy One
In the source org (typically a sandbox), go to Setup → Outbound Change Sets and click New.
Add the components (fields, objects, flows, Apex classes) that make up this specific change.
Upload the change set to the target org (this requires an established deployment connection).
In the target org, go to Inbound Change Sets, validate the change set, and review any errors.
Once validated successfully, deploy the change set to apply it.
A Real-World Example
A team builds and thoroughly tests a new approval process and its supporting custom fields entirely within a sandbox. Once validated, a single change set bundles the fields, the approval process, and the related page layout changes together, deploying all of it to production in one coordinated release rather than manually rebuilding each piece.
🚫 Common Mistake
Missing a dependent component in the change set -- deploying a Flow that references a custom field, without including that field in the same change set. The deployment fails validation, and tracking down exactly which dependency is missing can be genuinely tedious on a large change set.
💡 Pro Tip
For frequent or complex deployments, evaluate moving to Salesforce CLI and version-controlled metadata instead of change sets -- it's a bigger upfront investment but scales far better than manually managing change set components as your org grows.
Frequently Asked Questions
What\'s the difference between a change set and a package?
Change sets move metadata between two directly-connected orgs (like a sandbox and its production org) in a specific, one-time deployment; packages are more general-purpose, installable, and can be distributed independently of a direct org connection.
Can change sets deploy data, or only metadata?
Metadata only -- change sets move configuration (fields, flows, layouts, Apex) but never record data. Data migration requires a separate tool like Data Loader.
Why can\'t I find my sandbox in the deployment connections list?
Deployment connections must be explicitly enabled between the source and target org in Setup before a change set can be sent -- this isn't automatic for every sandbox by default.
Can a change set be deployed to any org?
No -- change sets can only move between orgs with an existing, established connection (typically a sandbox and its parent production org, or between sandboxes in the same hierarchy).
What happens if a change set deployment fails partway through?
Change set deployments are all-or-nothing -- if any component fails validation, the entire deployment is rolled back, not partially applied.
Can I edit a change set after it\'s been uploaded?
No, once uploaded, a change set is locked -- to make changes, you create a new change set rather than editing the existing one.
Do change sets include dependent metadata automatically?
Partially -- Salesforce attempts to identify dependencies, but complex dependency chains sometimes require manually adding related components that weren't automatically detected.
Is there a size limit for change sets?
Yes, a single change set is limited to 10,000 components -- large deployments sometimes need to be split across multiple change sets.
Can change sets be used for ongoing CI/CD pipelines?
Not ideally -- change sets are a manual, UI-driven process. Modern DevOps workflows typically use metadata API tools, Salesforce CLI, and version control instead, reserving change sets for simpler, less frequent deployments.
Can I deploy a change set to production without testing in a sandbox first?
Technically possible if connections allow it, but strongly discouraged -- validating in a sandbox first is the entire point of having a staged deployment process.
Related Articles