Salesforce DevOps Course Module 3: Change Sets Mastery — Complete Guide 2026

🚀 Free Salesforce DevOps Course 2026 Module 3 of 15

Change Sets Mastery
Complete Guide 2026

Master the full Change Set deployment workflow — from creating your first Change Set to troubleshooting failures, Quick Deploy, Profiles, limits, and knowing exactly when to graduate beyond Change Sets to SFDX.

Sections

Beginner

Free

Forever

2026

Updated

← Module 2 All Topics →

📍 Course Progress — Module 3 of 15

M1 ✅
Intro

M2 ✅
Sandboxes

M3 👈
Change Sets

M4
Metadata API

M5
Git Basics

M6
SFDX & CLI

M7
Scratch Orgs

M8
Packages

M9
DevOps Center

M10
Deploy Strategy

M11
GitHub Actions

M12
Advanced CI/CD

M13
Unlocked Pkg

M14
Enterprise

M15
Capstone

✅ Completed: M1 — Intro to Salesforce DevOps | M2 — Environments & Sandboxes ← Review M2

📋 What You Will Learn in This Module

📦 What is a Change Set? 🔗 Deployment Connections 🛠️ Creating Your First Change Set ✅ Validate vs Deploy vs Quick Deploy 👤 Profiles & Permission Sets 📏 Limits & Restrictions 🔧 Troubleshooting Failures 🗑️ Deleting Components 💡 Change Set Best Practices ⚠️ Common Mistakes 🚪 When to Graduate Beyond Change Sets 📝 Module Quiz

📚 Full Course Navigation

✅ M1 — What is Salesforce DevOps? ✅ M2 — Environments & Sandboxes M3 — Change Sets Mastery 👈 M4 — Metadata API Basics M5 — Version Control with Git M6 — SFDX & SF CLI Setup M7 — Scratch Orgs M8 — Salesforce Packages M9 — DevOps Center M10 — Deployment Strategies M11 — GitHub Actions CI/CD M12 — Advanced CI/CD Patterns M13 — Unlocked Packages M14 — Enterprise DevOps M15 — Capstone Project

📦 Section 1 — What is a Change Set?

The foundation of Salesforce deployment — every admin and developer must know this

📖 Definition

A Change Set is Salesforce's built-in deployment tool — a container that packages metadata components (Apex classes, LWC, fields, flows, page layouts) and moves them from one org to another through an established deployment connection.

No CLI. No coding. No external tools. Just Salesforce Setup — which is why every admin and developer starts here.

✅ Two Types of Change Sets

Type	Where Created	What It Does
📤 Outbound Change Set	Source org (your sandbox)	You add components and upload to the target org
📥 Inbound Change Set	Target org (production)	You receive and deploy from the source org

🎯 Real World Analogy

Think of a Change Set like a courier package:

You pack your items (components) into a box (Outbound Change Set), send it to the recipient address (upload to target), the recipient receives the package (Inbound Change Set), opens it, checks the contents (validate), and accepts delivery (deploy).

The courier route (deployment connection) must exist before any package can be sent.

📊 What Can You Include in a Change Set?

✅ Can Include	❌ Cannot Include
Apex classes and triggers	Data records (Account, Contact, etc.)
Lightning Web Components	Documents and attachments
Aura components	Deleted components
Flows and Process Builder	Users and their settings
Custom objects and fields	Dashboards and reports (must recreate)
Page layouts and record types	Org-wide settings (must configure manually)
Profiles and Permission Sets	Connected App credentials
Email templates	Named Credential secrets
Custom labels	Scheduled jobs

🔗 Section 2 — Deployment Connections

The prerequisite for every Change Set — how to set up the trust relationship between orgs

📖 What is a Deployment Connection?

A Deployment Connection is a trust relationship between two Salesforce orgs that authorizes Change Sets to flow between them. Without this connection, you cannot send or receive Change Sets — it is like trying to send a courier without a valid delivery route.

✅ How to Set Up a Deployment Connection

Log into Production org → Setup → Deploy → Deployment Settings

Find your sandbox in the list → click Edit → check "Allow Inbound Changes"

Log into Sandbox → Setup → Deploy → Deployment Settings

Find Production in the list → click Edit → check "Allow Inbound Changes"

Connection is now established — both orgs trust each other

🔑 Key Rules of Deployment Connections

Production automatically connects to ALL its sandboxes — you just need to authorize
Sandbox-to-sandbox connections must be manually enabled from both sides
Cannot deploy FROM production TO sandbox using Change Sets — one directional
Only works between orgs in the same Salesforce instance/environment
Unrelated orgs (different companies) cannot establish deployment connections

🏢 XYZ Company Connection Map

Anant-Dev
Sandbox

→

QA
Sandbox

→

UAT
Sandbox

→

Production

Each arrow represents an established Deployment Connection. Changes only flow forward — never backward using Change Sets.

🛠️ Section 3 — Creating Your First Change Set

Step-by-step walkthrough — from zero to successful deployment

📖 The Complete Change Set Workflow

Follow these exact steps every time you deploy using Change Sets. Skipping any step leads to errors or incomplete deployments.

✅ Phase 1 — Create Outbound Change Set (Source Sandbox)

Setup → Deploy → Outbound Change Sets → New

Name your Change Set — use a clear, descriptive name
Good: "Visit_Report_LWC_v1" | Bad: "Changes" or "Test123"

Add a Description — what this Change Set contains and why
Example: "Adds Visit Report LWC with pagination and quality rating fields"

Click Add → Select components to include
Add by metadata type — Apex Class, LWC, Custom Field, etc.

Click "View/Add Dependencies" — always check this!
Salesforce shows you components that your selections depend on

Add all dependency components to the Change Set
Missing dependencies = deployment failure

Click Upload → Select target org → Click Upload
Change Set is now sent to the target org

📋 Phase 2 — Deploy Inbound Change Set (Target Org)

Log into Target Org (Production)

Setup → Deploy → Inbound Change Sets
Find your Change Set — status should be "Awaiting Deployment"

Click Validate FIRST — never deploy without validating
This runs all Apex tests without making changes — your safety net

Wait for validation to complete — check for errors
If validation fails: read the error log, fix in sandbox, re-upload

If validation passes → Click Deploy (or Quick Deploy within 10 days)
All changes are now applied to the target org ✅

💡 Naming Convention Best Practice

Format	Example	Why
FeatureName_Type_Version	VisitReport_LWC_v1	Clear what it contains
TicketNumber_Description	JIRA-245_OrderTriggerFix	Links to work item
Date_Description	2026May_QuarterlyRelease	Easy to find by date

❌ Never name Change Sets: "test", "changes", "temp", "urgent" — you will regret it in 6 months when you can't remember what it contained.

🏢 XYZ Company Example

Anant built a new Visit Report LWC at XYZ Company. He created an Outbound Change Set named "VisitReport_LWC_v2" with description "Adds cursor pagination, quality rating system, and dual export options." He added: the LWC component, VisitReportController Apex class, VisitReportControllerTest, 3 custom fields on the Visit_Report__c object, and the Permission Set. He clicked View Dependencies — Salesforce flagged the Visit_Report__c object itself as a dependency. He added it, uploaded to Production, validated (28 minutes, 487 tests passed), then Quick Deployed — live in production in 90 seconds. ✅

✅ Section 4 — Validate vs Deploy vs Quick Deploy

The most important distinction in Change Set deployments — understanding each option

📖 Why Three Options?

Salesforce designed three deployment actions to give you control over when tests run and when changes are applied. Understanding all three is what separates professional deployments from risky ones.

✅ Option 1 — Validate

What it does: Runs all Apex tests. Checks for errors. Verifies everything will work. Makes ZERO changes to the org.

When to use: Always before any production deployment. Use during business hours so test results are ready by your deployment window.

Output: Success (tests pass, ready for deploy) or Failure (error log shows exactly what broke)

Time: Same as a real deployment — can take 20-60 minutes depending on test suite size

Bonus: A successful validation is valid for 10 days — enabling Quick Deploy

🟡 Option 2 — Deploy

What it does: Runs all Apex tests AND applies all metadata changes to the org.

When to use: When you haven't validated recently and want to deploy in one step. Or for non-production deployments where speed matters more than caution.

Risk: If tests fail halfway through, Salesforce auto-rolls back everything. Production is safe but you've wasted time.

Best practice: Always validate separately first — then use Quick Deploy for the actual production deployment.

✅ Option 3 — Quick Deploy (The Professional's Choice)

What it does: Uses the CACHED results from your previous successful validation to deploy instantly — WITHOUT re-running all tests.

When to use: Within 10 days of a successful validation. This is the standard approach for production deployments.

Time: Seconds to a few minutes (no test execution!)

Availability: Only available if validation passed within the last 10 days

Why it matters: If you have 800 test classes that take 45 minutes — validate on Sunday night, Quick Deploy Monday morning. Production downtime goes from 45 minutes to 2 minutes.

📊 Side-by-Side Comparison

Feature	✅ Validate	🚀 Deploy	⚡ Quick Deploy
Runs Apex tests?	✅ Yes	✅ Yes	❌ Uses cache
Makes changes?	❌ No	✅ Yes	✅ Yes
Speed	Slow (tests run)	Slow (tests run)	Fast (no tests)
Prerequisite	None	None	Successful validation within 10 days
Best for	Pre-deploy check	One-step deploy	Production deployment
Production recommended?	✅ Always first	⚠️ Risky alone	✅ After validation

🏢 XYZ Company Deployment Pattern

Sunday 10 PM
Validate

→

45 mins
Tests Pass ✅

→

Monday 9 AM
Quick Deploy

→

90 seconds
Live! 🚀

XYZ Company's standard release pattern — zero risk, minimal production downtime, and the team comes in Monday morning to a successful deployment.

👤 Section 5 — Profiles & Permission Sets in Change Sets

The most misunderstood area of Change Set deployments — get this wrong and you can break production access

📖 Why This is Tricky

Profiles and Permission Sets control access — who can see what, who can do what. Including the wrong one in a Change Set can accidentally remove access for hundreds of users in production. This section could save your career. 😅

✅ Permission Sets — Always Safe to Include

Permission Sets are additive — they only ADD permissions, never remove them. Including a Permission Set in a Change Set deploys the additional permissions without touching anything else in the org.

Best practice: Always build new feature access using Permission Sets, not Profiles. Deploy them in Change Sets without fear.

Scenario	Action
New LWC needs access	Create Permission Set, add to Change Set ✅
New custom object access	Create Permission Set, add to Change Set ✅
New field visibility	Add to Permission Set, include in Change Set ✅

⚠️ Profiles — Handle With Extreme Caution

Profiles are destructive when included in Change Sets — they FULLY OVERWRITE the profile in the target org. Every setting in the profile gets replaced with what's in your Change Set.

❌ Profile in sandbox has 50 object permissions → Profile in production has 80 → Deploy sandbox Profile → Production now has only 50 permissions. 30 permissions silently removed!
❌ Sales team loses access to 30 objects — they can't do their jobs
❌ You get 50 angry Slack messages at 9 AM on Monday

Only include a Profile in a Change Set when you specifically need to deploy Profile-level settings AND you have compared the full Profile between sandbox and production.

📊 Profile vs Permission Set Decision

Situation	Include Profile?	Include Permission Set?
New LWC visibility on page layout	⚠️ Maybe (for layout assignment)	✅ Yes (for component access)
New custom object CRUD access	❌ Avoid	✅ Yes
New field visibility	❌ Avoid	✅ Yes
Default record type assignment	⚠️ Sometimes needed	❌ Not applicable
Tab visibility for new object	❌ Avoid	✅ Yes

💡 The Golden Rule

If you can do it with a Permission Set — do it with a Permission Set. Profiles in Change Sets are a last resort, not a first choice. XYZ Company has a strict rule: no Profile is included in a Change Set without a second developer reviewing the change.

📏 Section 6 — Change Set Limits & Restrictions

Know these before you hit them in production

✅ Hard Limits

Limit	Value	What to Do When You Hit It
Max files per Change Set	10,000 files	Split into multiple Change Sets, deploy in dependency order
Max total size	400MB	Split into smaller Change Sets
Outbound Change Set expiry	30 days	Upload again before expiry or re-create
Quick Deploy window	10 days	Re-validate if window expired
Min Apex test coverage	75% overall	Write more test methods before deploying

❌ What Change Sets Cannot Do

❌ Cannot delete metadata components (use destructive changes XML — covered in M4)
❌ Cannot deploy data records — metadata only
❌ Cannot be automated — purely manual process
❌ Cannot be cloned or templated — recreate from scratch each time
❌ Cannot be used between unrelated orgs (different companies)
❌ Cannot deploy from production to sandbox
❌ Cannot be rolled back after a successful deployment
❌ Cannot partially deploy — all or nothing

💡 Apex Test Coverage Requirements

Requirement	Rule
Overall org coverage	Minimum 75% to deploy to production
Individual trigger coverage	Every trigger must have at least 1% coverage (at least 1 test)
Best practice target	80%+ coverage (XYZ Company targets 85%)
Tests must pass	100% of tests must pass — even one failure blocks deployment

🔧 Section 7 — Troubleshooting Change Set Failures

Every error explained — and exactly how to fix it

📖 The Golden Rule of Failures

When a Change Set deployment fails, Salesforce automatically rolls back ALL changes. The target org is completely unaffected — it is exactly as it was before you started. You can always try again safely.

Never panic. Read the error log. Fix the issue. Redeploy.

❌ Error Type 1 — Apex Test Failure

Error message: "Test failure — MyTestClass.testMethod: System.AssertException: Assertion Failed"

Why it happens: An Apex test class is failing — either because your new code broke existing functionality, or the test is poorly written.

Step 1: Copy the test class name from the error log
Step 2: Run that specific test in your sandbox (Setup → Apex Test Execution)
Step 3: Read the assertion error — what expected vs what got
Step 4: Fix either the code or the test class
Step 5: Re-add fixed class to Change Set → Re-upload → Validate again

❌ Error Type 2 — Missing Dependency

Error message: "No such column 'Custom_Field__c' on entity 'Account'"

Why it happens: Your Apex class or LWC references a field, object, or component that doesn't exist in the target org AND wasn't included in the Change Set.

Step 1: Check what component the error is referencing
Step 2: Go back to your Outbound Change Set in sandbox
Step 3: Add the missing component (field, object, etc.)
Step 4: Re-upload → Re-validate

❌ Error Type 3 — Code Coverage Below 75%

Error message: "Overall code coverage is 68%, which is below the required 75%"

Step 1: Run all tests in sandbox to see current coverage percentage
Step 2: Check which Apex classes have low coverage (Setup → Apex Classes → Code Coverage)
Step 3: Write more test methods for low-coverage classes
Step 4: Add updated test classes to Change Set → Re-upload → Re-validate

❌ Error Type 4 — Profile/Permission Conflict

Error message: "Field does not exist: Account.Custom_Field__c — included in Profile: Admin"

Why it happens: Your Profile references a field that exists in sandbox but not yet in production.

Step 1: Add the missing custom field to your Change Set
Step 2: OR remove the Profile from the Change Set and configure field visibility manually

❌ Error Type 5 — Inactive Flow Version

Error message: "The flow version referenced is inactive"

Step 1: In sandbox, make sure the Flow you're deploying is in Active status
Step 2: Re-add the Flow to the Change Set
Step 3: Re-upload and validate

✅ Troubleshooting Workflow

Deployment
Failed

→

Read
Error Log

→

Fix in
Sandbox

→

Re-Upload
Change Set

→

Validate
Again ✅

🗑️ Section 8 — Deleting Components with Change Sets

The most asked question about Change Sets — and the surprising answer

❌ You Cannot Delete Components Using Change Sets

This is the most common shock for new Salesforce developers — Change Sets have NO delete capability. You cannot use a Change Set to remove an Apex class, custom field, or any other component from the target org.

✅ How to Delete Components — Your Options

Method	How	Difficulty
Manual deletion (Setup UI)	Log into production → Setup → Find component → Delete	Easy
Destructive Changes XML (SFDX)	Create destructiveChanges.xml → deploy via CLI	Intermediate (covered in M4)
Workbench	Create package.xml + destructiveChanges.xml → deploy via Workbench	Intermediate

💡 For Beginners — Manual Deletion is Fine

If you are still in the Change Sets phase of your DevOps journey, manually deleting components in production is perfectly acceptable. It is manual, but for occasional deletions it is the simplest approach.

When you learn SFDX (Module 6) and Metadata API (Module 4), you will have programmatic deletion available through destructive changes XML — the professional approach for frequent deletions.

🏢 XYZ Company Example

XYZ Company needed to remove a deprecated Lead_Source_Old__c field. Since Change Sets can't delete, Meera (admin) logged directly into production, navigated to Setup → Object Manager → Lead → Fields → Lead_Source_Old__c → Delete. Done in 2 minutes. For small, infrequent deletions — this is the right approach. For bulk deletions of 20+ components, they use SFDX destructive changes.

💡 Section 9 — Change Set Best Practices

Professional habits that separate great Salesforce developers from everyone else

✅ The 10 Golden Rules of Change Sets

Always validate before deploying to production — no exceptions, ever

Use meaningful names and descriptions — you will thank yourself in 6 months

Always check View/Add Dependencies — missing dependencies = deployment failure

Test everything in sandbox before creating the Change Set — never deploy untested code

Validate during business hours, deploy in maintenance windows — minimize user impact

Use Quick Deploy — validate off-hours, deploy instantly during the window

Prefer Permission Sets over Profiles — never include Profiles without careful review

Keep Change Sets small and focused — one feature per Change Set, easier to troubleshoot

Document what you deployed and when — keep a deployment log spreadsheet

Always have a rollback plan — know what you'll do if something goes wrong after deployment

📋 XYZ Company Deployment Checklist

Stage	Checklist Item	Who
Pre-Deploy	Feature tested in sandbox ✅	Developer
Pre-Deploy	All new Apex has test classes ✅	Developer
Pre-Deploy	Coverage above 85% in sandbox ✅	Developer
Pre-Deploy	Dependencies checked and added ✅	Developer
Pre-Deploy	Change Set named and described ✅	Developer
Deploy	Validated in production ✅	Admin
Deploy	Quick Deployed in maintenance window ✅	Admin
Post-Deploy	Smoke tested in production ✅	QA
Post-Deploy	Deployment logged in tracker ✅	Admin

⚠️ Section 10 — Common Change Set Mistakes

Learn from the most expensive mistakes Salesforce teams make

❌ Mistake 1 — Skipping Validation Before Production Deployment

What happens: Developer deploys directly without validating. A test fails halfway through. Salesforce rolls back. It is 2 AM. You start over.
The fix: Always validate first. Always. No exceptions.

❌ Mistake 2 — Not Checking Dependencies

What happens: Apex class references a custom field. Custom field not in Change Set. Deployment fails with "No such column" error. 45 minutes of test running — wasted.
The fix: Always click "View/Add Dependencies" after adding components. Add ALL flagged dependencies.

❌ Mistake 3 — Including Full Profiles Without Comparison

What happens: Sandbox Profile has fewer permissions than production (because sandbox is older). Deploying it overwrites production Profile. Users lose access to 20 objects at 9 AM Monday.
The fix: Use Permission Sets. If you must include a Profile, compare it field by field between sandbox and production first.

❌ Mistake 4 — Deploying Too Many Things at Once

What happens: One massive Change Set with 150 components from 5 different features. Deployment fails. Now you don't know WHICH feature caused it. Roll back everything. Start debugging from scratch.
The fix: One Change Set per feature. Small, focused, testable.

❌ Mistake 5 — Deploying Active Flows Without Testing

What happens: Flow was working in sandbox. Deploy to production. Flow has a hardcoded sandbox record ID that doesn't exist in production. Every time the Flow runs — error. Users start calling support.
The fix: Never hardcode IDs in Flows. Test Flows in QA sandbox with a fresh dataset that mirrors production. Check all Get Records and Create Records elements carefully.

🚪 Section 11 — When to Graduate Beyond Change Sets

Knowing when you have outgrown Change Sets is a sign of professional maturity

📖 Change Sets Are a Starting Point, Not the Destination

Change Sets are excellent for learning, for small teams, and for simple deployments. But there comes a point — and it comes quickly — when Change Sets become the bottleneck. Recognizing that moment is important.

🚨 Signs You Have Outgrown Change Sets

🔴 Two developers overwrote each other's work — time for Git branches
🔴 You have no idea what is in production vs sandbox — time for version control
🔴 Deployment day is stressful and quarterly — time for CI/CD automation
🔴 You need to delete components regularly — time for SFDX destructive changes
🔴 More than 3 developers on the same project — time for Scratch Orgs
🔴 You are deploying to unrelated orgs — time for Metadata API
🔴 Business wants features delivered weekly, not quarterly — time for CI/CD

✅ What Comes Next — Your SFDX Journey

Module	What You Learn	Replaces
M4 — Metadata API	package.xml, Workbench, programmatic deploy	Change Set manual process
M5 — Git Basics	Version control, branches, commits	No version history problem
M6 — SFDX & CLI	sf commands, source format, automation	Manual GUI deployments
M7 — Scratch Orgs	Isolated dev environments	Shared sandbox conflicts
M11 — GitHub Actions	Full CI/CD automation	Manual deployments entirely

💡 Important — Change Sets Still Have a Place

Even teams using full SFDX and CI/CD still use Change Sets for: emergency hotfixes by admins, simple config-only changes, and training new team members. Change Sets are not bad — they are just not enough on their own for professional teams. Think of them as your foundation, not your ceiling.

🏢 XYZ Company — Today vs Before

Before DevOps (Change Sets Only)	After DevOps (SFDX + CI/CD)
Quarterly deployments, 2 AM Sunday stress	Tuesday/Friday deployments, automated
Developers overwriting each other	Feature branches, zero conflicts
No version history	Full Git audit trail
"What's in production?" — nobody knows	Git repo = exact production state
3 months to deliver a feature	1-2 weeks from idea to production

📝 Section 12 — Module 3 Quiz

Test your Change Sets mastery before moving to Module 4

🧠 Module 3 Knowledge Check — 10 Questions

Q1. What are the two types of Change Sets?

A) Outbound and Inbound ✅

B) Upload and Download

C) Source and Target

D) Deploy and Validate

Q2. What does Validate do in a Change Set deployment?

A) Deploys all components to production

B) Runs all Apex tests and checks for errors WITHOUT making any changes ✅

C) Creates a backup of production

D) Uploads the Change Set to the target org

Q3. How long is a successful validation result valid for Quick Deploy?

A) 24 hours

B) 5 days

C) 10 days ✅

D) 30 days

Q4. Why are Profiles dangerous to include in Change Sets?

A) They increase the Change Set size

B) They fully overwrite the target Profile, potentially removing existing permissions ✅

C) They slow down the deployment

D) They require separate authentication

Q5. What is the maximum number of files in a Change Set?

A) 1,000

B) 5,000

C) 10,000 ✅

D) 50,000

Q6. What happens when a Change Set deployment fails in production?

A) All changes are permanently applied

B) Half the components are deployed

C) Salesforce automatically rolls back ALL changes — production is unaffected ✅

D) You must manually rollback each component

Q7. Can you use Change Sets to delete a custom field from production?

A) No — Change Sets cannot delete components ✅

B) Yes — add the field to the Change Set and select "Delete"

C) Yes — use the Destructive Changes option in Change Sets

D) Only if you are a System Administrator

Q8. What is the minimum Apex test coverage required to deploy to production?

A) 50%

B) 60%

C) 75% ✅

D) 90%

Q9. What should you ALWAYS check after adding components to a Change Set?

A) The Change Set size

B) View/Add Dependencies ✅

C) The deployment connection

D) The sandbox refresh date

Q10. What is the best deployment pattern for production using Change Sets?

A) Deploy directly without testing

B) Validate and Deploy at the same time

C) Validate during off-hours → Quick Deploy in the maintenance window ✅

D) Deploy multiple Change Sets simultaneously

✅ Answer Key

A, B, C, B, C, C, A, C, B, C — Score 9-10: Change Sets master! Ready for M4. Score 7-8: Review Sections 4 and 7. Score below 7: Re-read the full module.

📋 Module 3 Summary

Everything you mastered in this module

✅ What You Learned in Module 3

✅ Change Sets are Salesforce's built-in deployment tool — Outbound (send) and Inbound (receive)
✅ Deployment Connections must be established between orgs before Change Sets can flow
✅ Full 7-step deployment workflow — create, add components, check dependencies, upload, validate, deploy
✅ Validate = dry run (no changes). Deploy = actual changes. Quick Deploy = instant deploy using cached validation
✅ Always validate first, use Quick Deploy in the maintenance window — the professional standard
✅ Permission Sets are safe to include. Profiles are dangerous — they fully overwrite target settings
✅ Limits: 10,000 files, 400MB, 75% test coverage, 10-day Quick Deploy window
✅ Failed deployments auto-rollback — production is always safe
✅ Change Sets cannot delete components — use manual Setup UI or SFDX destructive changes
✅ Signs you've outgrown Change Sets: overwrites, no version history, quarterly deployments, 3+ developers

🎤 Module 3 One-Line Summary

"Change Sets are Salesforce's built-in metadata deployment tool — always validate before production, use Quick Deploy in maintenance windows, prefer Permission Sets over Profiles, and recognize when your team has outgrown them and needs SFDX."

➡️ Next: Module 4 — Metadata API Basics

Learn package.xml, Workbench deploy/retrieve, destructive changes to delete components, and how the Metadata API powers everything under the hood

Module 4 →

🚀 Enjoying This Free DevOps Course?

Share it with your Salesforce community. 22,000+ learners this month — all free, forever.

All Free Resources → 75 DevOps Q&As →