Salesforce Dictionary - Free Salesforce GlossarySalesforce Dictionary
DictionaryCChange Set
AdministrationIntermediate

Change Set

A Change Set is a Salesforce deployment tool used to send customizations and configurations from one org to another, typically from a sandbox to production.

Β§ 01

Definition

A Change Set is a Salesforce deployment tool used to send customizations and configurations from one org to another, typically from a sandbox to production. Change Sets can include components like custom objects, fields, Apex classes, Flows, page layouts, and profiles. They require a deployment connection between the source and target orgs.

Β§ 02

In plain English

πŸ‘‹ Study buddy

β€œHere's a simple way to think about it: Change Sets are the slow, safe path between sandbox and prod. Components selected and sent across deployment connections - no command line, no merge conflicts. Also no version control or rollback.”

Β§ 03

Worked example

scenario Β· real-world use

After building and testing a new Approval Process and three Apex triggers in the staging sandbox, the admin at SilverLine creates an Outbound Change Set containing all the components. She uploads it to production, where another admin validates the set by running all tests. Once validation passes with zero errors, they deploy the Change Set during a scheduled maintenance window.

Β§ 04

Why Change Sets are the slow, safe path between sandbox and prod

A Change Set is the declarative way to move work from one Salesforce org to another - usually sandbox to production. You add components (a custom object, a Flow, a profile, a page layout) to an outbound set in the source org, send it across an established deployment connection, and then validate and deploy it in the target. There is no command line, no merge conflict, no manual file shuffling. There is also no version control, no diff, and no rollback once it lands.

Most admin teams know Change Sets as the deployment tool that works without buy-in from engineering - and as the one that breaks down once your release process gets serious. They are slow to assemble for large changes, easy to forget components on (a missing dependency surfaces only when validation fails), and hard to audit after the fact because the set itself disappears once deployed. The platform's modern answer is the Salesforce CLI, DX, and Git-based deployment, and most growing orgs eventually graduate. But Change Sets remain a fine choice for small, occasional, low-risk moves - and they are still the easiest deployment path to teach a new admin.

Β§ 05

How to set up Change Set

Change Sets are Salesforce's built-in deployment mechanism for moving metadata between connected orgs (Sandbox β†’ Production, or between Sandboxes). They're slow, manual, and the modern alternative is Salesforce DX or third-party tools like Copado / Gearset β€” but Change Sets remain the path of least friction for small admin-led deploys.

  1. Verify Deployment Connection between source and target orgs

    In the target org: Setup β†’ Deployment Settings β†’ Edit the connection from the source β†’ tick Allow Inbound Changes. Without this, the target won't accept the change set.

  2. In the source org: Setup β†’ Outbound Change Sets β†’ New

    Setup β†’ Quick Find: Outbound Change Sets β†’ New.

  3. Name the Change Set and add Description

    Naming convention: "<feature> - <ticket #> - <YYYY-MM-DD>".

  4. Add Change Set Components

    Click Add. Pick Component Type, then individual items. Add View / List Dependencies after to pull in everything that has to deploy together.

  5. Click Upload

    Pick the target org. Upload sends the change set across the deployment connection.

  6. In the target org: Setup β†’ Inbound Change Sets β†’ click Validate

    Validates against the target without committing. Surfaces test-coverage and missing-dependency errors.

  7. Click Deploy

    After successful validation, click Deploy. The metadata is committed.

Key options
Component Type filterremember

Picks the metadata category (Apex Class, Validation Rule, Page Layout, Custom Object, etc.).

View / List Dependenciesremember

Salesforce calculates what else has to deploy with each component. Always run this β€” missing dependencies cause deploy failures.

Validate vs Deployremember

Validate checks without committing. Deploy commits. Many teams Validate twice before Deploy.

Run Testsremember

Default: tests in the deployed components. Options: Run Specified Tests, Run Local Tests, Run All Tests in Org. Production deploys to require β‰₯75% test coverage.

Gotchas
  • Change Sets cannot delete metadata. To remove a field or page layout in the target, you have to do it manually. Modern alternatives (DX, Gearset) handle deletes automatically.
  • The list of supported component types in Change Sets is incomplete β€” record types, custom labels, and several others can't be moved via Change Set. Salesforce maintains a list at developer.salesforce.com.
  • Production deploys require β‰₯75% test coverage across changed Apex. A clean Change Set can fail at Deploy time because of test coverage, leaving you to scramble to add tests fast. Validate early to catch this before deploy day.
Β§ 06

How organizations use Change Set

Atlas Manufacturing

Used Change Sets for small admin-driven changes; appropriate tool for that scale of work.

BlueRiver Health

Migrated complex deployments to DevOps Center; Change Sets retained for occasional small moves.

Β§

Trust & references

Official documentation

Straight from the source - Salesforce's reference material on Change Set.

Was this entry helpful?
Help us write better definitions. Quick reactions or detailed edit suggestions.
Β§

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…

Loading discussion…