Change Set
A Change Set is a Salesforce-native package of metadata components (custom fields, page layouts, Flows, Apex classes, Permission Sets, Validation Rules, Lightning Pages, and many other types) that an admin builds in one org and deploys to a connected org.
Definition
A Change Set is a Salesforce-native package of metadata components (custom fields, page layouts, Flows, Apex classes, Permission Sets, Validation Rules, Lightning Pages, and many other types) that an admin builds in one org and deploys to a connected org. Change Sets are the traditional sandbox-to-production deployment path: build in a sandbox, package the changes into an Outbound Change Set, send to production, receive in production as an Inbound Change Set, validate, deploy. The mechanism predates Salesforce DX and remains in wide use, particularly for admin-led deployments that do not involve source control.
Change Sets exist because most Salesforce deployments need to move metadata between environments without source-tracking discipline. They are the lowest-friction deployment path: no command line, no Git, no separate deployment tool. The trade-off is that Change Sets do not support some modern metadata types (newer features ship as DX-only), do not include modification history, and can be tedious when many components need to ship together. Most production orgs use Change Sets alongside source-tracked deploys, picking the tool based on the change type and the team's source-control posture.
Why Change Sets persist as the admin deployment default despite newer tools
The Outbound and Inbound Change Set flow
Change Sets always travel between two connected orgs. In the source org (typically a sandbox), the admin creates an Outbound Change Set, adds the metadata components to deploy, uploads the Change Set to the target org. In the target org (typically production), the admin opens Inbound Change Sets, finds the uploaded Change Set, runs Validate (a deploy dry-run that checks for errors without committing), then Deploy. The same Change Set can be deployed to multiple connected orgs sequentially; once deployed, the Change Set status moves from Validated to Deployed.
Deployment Connections and the trust setup
Two orgs must have a Deployment Connection configured before Change Sets can flow between them. Setup, Deployment Settings, create connection. The connection is two-way for awareness but the deployment direction is one-way per connection (sandbox to production, not production to sandbox unless explicitly opened). Most orgs configure connections at sandbox creation time and forget about them; the connection setting is the first place to check when a Change Set upload fails with a "no connection" error.
Component types supported and not supported
Change Sets support most common metadata types: custom fields, page layouts, Validation Rules, Workflow Rules, Flows, Apex classes and triggers, Permission Sets, Lightning Pages, custom objects, custom labels, custom metadata types, custom tabs. The Components page in the Outbound Change Set has a comprehensive type list. Notable gaps: some newer feature types (Agentforce metadata, certain Data Cloud configurations, some Industries Cloud components) ship as DX-only and require source-tracked deploys. The Components page is the source of truth for what is and is not supported; check before assuming a specific type will work.
Dependencies and the View/Add Dependencies button
Most metadata components depend on other components: a Validation Rule depends on the fields it references, a Page Layout depends on the fields it shows, a Flow depends on the objects and fields it reads. Change Sets do not auto-include dependencies. The View/Add Dependencies button shows which components the current Change Set components depend on and lets the admin add them with one click. Skipping this step is the most common cause of failed deploys; the target org rejects a Validation Rule that references a field that does not exist in the target.
Validate before Deploy
Validate is a dry-run of the deployment. It runs all the same checks as Deploy (dependency resolution, code compilation, test execution if test classes are included) but does not commit changes. A successful Validate is the green light to Deploy. A failed Validate produces an error report; the admin fixes the underlying issues in the source org, re-uploads, re-validates. Always Validate before Deploy on production; the small extra step prevents the partial-deploy state that occurs when Deploy fails partway through.
Apex test requirements for production deploys
Production deploys that include Apex code require 75 percent test coverage across the org's Apex (a Salesforce-platform-wide rule, not per-Change Set). The Change Set deploy can run all local tests, specified tests, or a custom subset; the right choice depends on coverage state. Sandboxes do not have the 75 percent requirement, so a deploy that worked in sandbox can fail in production if test coverage is borderline. Run the production-eligible test suite in sandbox before deploying to catch coverage issues early.
When to use Change Sets vs source-tracked deploys
Change Sets are best for admin-led changes (page layouts, fields, Flows, validation rules) where source control is overkill. Source-tracked deploys (DevOps Center, third-party tools like Gearset or Copado) are best for code changes, multi-developer collaboration, and any deploy where rollback or diff visibility matters. Most orgs run both; admins use Change Sets for routine changes, developers use source-tracked deploys for code. Picking the right tool per change reduces friction; forcing all changes through one tool produces unnecessary process.
How to deploy a Change Set without surprises
The successful pattern: build the change, add dependencies, validate, deploy. The failed pattern: build the change, deploy, discover missing dependencies in production, scramble to fix. Validate is the safety net; skipping it is the most reliable way to create deployment incidents.
- Confirm the Deployment Connection exists
Setup, Deployment Settings in both orgs. The connection must exist and allow inbound deploys from source to target. Configure once if needed.
- Create the Outbound Change Set in the source org
Setup, Outbound Change Sets, New. Name it descriptively (date, ticket reference, change summary).
- Add the metadata components
Click Add. Pick the component type, select the components. Repeat for each type. The Components list grows as you add.
- Run View/Add Dependencies
Click View/Add Dependencies. Review the list. Add every dependency unless you know the target org already has it. Re-run after adding new components.
- Upload the Change Set to the target org
Click Upload, pick the target connection. The Change Set travels to the target as an Inbound Change Set.
- Validate in the target org before deploying
In the target org, Setup, Inbound Change Sets, find the uploaded set, click Validate. Wait for the dry-run to complete. Fix errors and re-upload if needed.
- Deploy after Validate succeeds
Click Deploy. Pick the test execution scope (run local tests, specified tests, all tests). Wait for completion. Verify the deployed components in the target org.
The two orgs connected for deployment. Configure once at sandbox creation.
Which metadata components are in the Change Set. Use View/Add Dependencies to avoid missing pieces.
Validate is a dry-run; Deploy commits. Always Validate first on production.
Local tests, specified tests, or all tests. Drives required test runtime; pick the right scope to balance coverage and time.
After a successful Validate, the Quick Deploy option skips re-running tests on the actual Deploy. Useful for tight production windows.
- Skipping View/Add Dependencies is the most common deploy failure cause. The target org rejects components that reference missing dependencies.
- Some newer metadata types are not supported in Change Sets. Confirm component type support before assuming a Change Set is the right path.
- Production deploys with Apex require 75 percent org-wide test coverage. A sandbox deploy that worked can fail in production if coverage is borderline.
- Validate and Deploy run tests if Apex is included. Test execution can take 30+ minutes on large orgs; plan for the time.
- Change Sets cannot be edited after upload. Mistakes require building and uploading a new Change Set; the original cannot be modified in flight.
Trust & references
Cross-checked against the following references.
- Change Sets referenceSalesforce
- Deployment overviewSalesforce
Straight from the source - Salesforce's reference material on Change Set.
- Change SetsSalesforce Help
- Outbound Change SetsSalesforce Help
- Deployment OverviewSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. Why is understanding Change Set important for Salesforce admins?
Q2. In which area of Salesforce would you typically find Change Set?
Q3. What is the primary benefit of Change Set for Salesforce administrators?
Discussion
Loading discussion…