One of the first scary moments for many Salesforce beginners happens when someone says:

“Now deploy it to Production.”

Creating fields, Flows, validation rules, or Apex inside a Sandbox feels safe.

But moving those changes into Production is where real deployment concepts begin.

That is exactly where Salesforce Change Sets come into the picture.

For many admins, Change Sets are the first step into Salesforce deployment and DevOps processes.

And even though modern DevOps tools are growing quickly, Change Sets are still heavily used in thousands of Salesforce orgs today.

Contents

What are Salesforce Change Sets?

Salesforce Change Sets are a deployment tool used to move metadata between related Salesforce orgs.

Most commonly:

Sandbox → Production
Sandbox → Sandbox

Change Sets help deploy metadata components like:

custom objects
fields
Flows
Apex classes
validation rules
page layouts
permission sets

But they do NOT move actual record data.

That is a very important concept beginners must understand early.

Metadata vs Data in Salesforce

This is where many beginners get confused.

Metadata

Metadata means Salesforce configuration.

Examples:

custom fields
Flows
Apex code
page layouts
validation rules

Data

Data means actual records stored inside objects.

Examples:

Account records
Contact records
Opportunity records

Change Sets only deploy metadata, not data.

If you are still learning Salesforce architecture, understanding metadata becomes much easier after working with Validation Rules, Flows, and Apex components.

Types of Change Sets in Salesforce

There are two types of Change Sets.

Outbound Change Set

This is created in the source org where changes were developed.

Example:

Sandbox → Outbound Change Set

You create and upload this to another org.

Inbound Change Set

This appears in the destination org after upload.

Example:

Production → Inbound Change Set

The target org validates and deploys it.

Real Example of Using Change Sets

Suppose an admin creates:

a new custom field
a validation rule
a Flow

inside a Sandbox.

Now those changes need to move into Production.

The deployment process usually looks like this:

Sandbox Development
        ↓
Outbound Change Set
        ↓
Upload to Production
        ↓
Inbound Change Set
        ↓
Validate
        ↓
Deploy

This is the standard beginner deployment workflow in Salesforce.

How to Create an Outbound Change Set

Go to:

Setup → Outbound Change Sets

Then:

Click New
Enter Name and Description
Save the Change Set
Add Components

Components may include:

fields
Flows
Apex classes
layouts
permission sets

Once components are added, Salesforce allows you to upload the Change Set.

Understanding Dependencies

Dependencies are one of the most important deployment concepts.

Suppose you deploy:

a validation rule

But that validation rule references:

another custom field

If the field is missing in Production, deployment fails.

That is why Salesforce provides:

View/Add Dependencies

This helps identify related components required during deployment.

Beginners often struggle with deployment failures because of missing dependencies.

Understanding object relationships and metadata dependencies becomes much easier after working with real admin configurations.

Uploading the Change Set

After adding components:

Click Upload
Select the target org
Confirm upload

Once uploaded:

the Change Set cannot be edited
you must clone it if changes are needed

This surprises many beginners during real deployments.

Deploying the Inbound Change Set

Inside the target org:

Setup → Inbound Change Sets

You will see:

Validate
Deploy
Delete

Validate

Validation checks:

missing dependencies
Apex test failures
deployment issues

Validation should ALWAYS be done before deployment.

Deploy

Deploy pushes metadata into the target org.

If deployment fails:

Salesforce rolls back the entire transaction

This means deployments are all-or-nothing.

Monitoring Deployment Status

Salesforce provides:

Deployment Status

This page shows:

deployment progress
success status
validation results
deployment errors

When deployments fail, this is where troubleshooting usually starts.

Components Supported in Change Sets

Common supported components include:

Supported Components
Custom Objects
Custom Fields
Validation Rules
Apex Classes
Apex Triggers
Flows
Permission Sets
Page Layouts

Components NOT Supported

Some components cannot be deployed through Change Sets.

Examples include:

Unsupported Components
Standard Picklist Values
Sales Processes
Organization Wide Email Addresses
Some Setup Configurations

These often require manual setup.

Change Sets vs Data Loader

This confuses beginners frequently.

Feature	Change Sets	Data Loader
Moves Metadata	Yes	No
Moves Records	No	Yes
Deployment Tool	Yes	No
Import/Export Data	No	Yes

If you need to move records, use tools like Data Loader instead.

Salesforce Data Loader Tutorial for Beginners

Change Sets vs Salesforce CLI

As developers grow, many eventually move beyond Change Sets.

Feature	Change Sets	Salesforce CLI
Beginner Friendly	High	Medium
UI Based	Yes	No
Version Control	Limited	Strong
Automation	Limited	Excellent
Enterprise DevOps	Medium	High

Change Sets are usually the starting point.

Modern DevOps pipelines often use:

Salesforce CLI
Git
CI/CD pipelines

Common Beginner Mistakes

Forgetting Dependencies

This is the most common deployment issue.

A component references another component that was not added to the Change Set.

Deploying Directly Without Validation

Always validate first.

Skipping validation increases deployment risk significantly.

Deploying Profiles Carelessly

Profiles often create deployment complications.

Many experienced teams prefer Permission Sets instead.

Making Changes Directly in Production

Beginners sometimes edit Production directly instead of using Sandboxes properly.

This creates long term deployment chaos.

Best Practices for Salesforce Change Sets

Always Use Sandbox Development

Never build directly in Production unless absolutely necessary.

Validate Before Deploying

Validation catches many deployment issues early.

Use Permission Sets More Than Profiles

Permission Sets are generally easier to deploy and maintain.

Deploy Small Logical Changes

Large deployments become harder to troubleshoot.

Document Deployments

Good deployment documentation helps teams avoid confusion later.

Real Project Scenario

Suppose a company wants to deploy:

new Opportunity fields
validation rules
automation Flows
permission changes

The admin creates everything inside a Sandbox first.

Then:

Creates an Outbound Change Set
Adds all metadata components
Uploads to Production
Validates deployment
Deploys successfully

This is one of the most common real Salesforce deployment workflows.

Limitations of Change Sets

Even though Change Sets are useful for beginners, they have limitations.

Some major limitations include:

no version control
difficult rollback handling
dependency management challenges
manual deployment process
weak collaboration support

That is why larger companies eventually move toward DevOps based deployment pipelines.

Pro Tip from Real Projects

Experienced Salesforce teams usually follow this mindset:

Small deployments are safer deployments.

Instead of deploying huge batches of changes together, they deploy smaller logical groups.

This makes troubleshooting much easier.

Conclusion

Salesforce Change Sets are one of the most important beginner deployment concepts to learn.

They help admins and developers:

move metadata safely
deploy changes between environments
validate configurations
understand deployment processes

And even though modern DevOps tools are becoming more popular, Change Sets still remain a practical starting point for understanding how Salesforce deployments work internally.

Once you understand Change Sets properly, learning advanced DevOps tools becomes much easier later.

FAQs