Salesforce Change Sets: What Nobody Bothers Explaining Properly

I’ve watched more Salesforce deployments go sideways than I care to count. Not because the platform is fragile — it’s not — but because people treat Change Sets like they’re a formality. Fill it up, click upload, hope for the best. That works until it doesn’t, and when it doesn’t, it’s usually a Friday at 4:45pm.

So let me walk through this the way I’d explain it to someone joining the team.

A Change Set is just a box. A very specific kind of box.

You’re moving something from one Salesforce org to another — maybe from a sandbox into production, maybe from one sandbox into a different one for UAT. You can’t just drag-and-drop metadata across orgs. Salesforce doesn’t work that way.

What you can do is collect all the pieces that belong to a particular change — your Apex classes, custom fields, workflow rules, whatever — put them into a Change Set, and ship that box over to the destination org in one go.

The part people miss: “related” isn’t optional. A Change Set where you’ve chucked in everything you touched this sprint without thinking about what actually needs to travel together is going to cause you problems. Maybe not immediately. But eventually.

There are two sides to this. You build an Outbound Change Set in your source org and upload it. On the other end, the destination org sees it as an Inbound Change Set — something sitting in a queue, waiting for someone to actually pull the trigger on deployment.

The actual steps, without the corporate fluff

Step 1 — Build the Outbound Change Set

Log into your source org. Gear icon, Setup, type “Outbound Change Sets” into Quick Find. Hit New Outbound Change Set.

Name it something that means something. Not “Changeset_v3_final.” Something like InvoiceModule_TaxFieldFix_Dec2024. You will thank yourself when you're staring at a list of these six months from now.

Add a description. Even two sentences. Future-you is reading this at midnight during an incident.

💡 Pick your destination org at this stage. If you don’t have a deployment connection set up between orgs, that’s a separate step — go to Setup → Deployment Settings and authorize the connection first.

Step 2 — Add your components

Click Add on the Change Set detail page. Search for whatever needs to go — Apex classes, triggers, custom objects, fields, Visualforce pages, profiles, permission sets.

Here’s where it actually matters: before you click “Add To Change Set,” pause and think about what depends on what.

Custom field without its parent object? That’s going to fail. Apex class that calls a custom setting you didn’t include? Also going to fail. Workflow rule referencing a picklist value that doesn’t exist in production yet? You see where this goes.

Map it out. Even a rough list on paper. The five minutes this takes is worth more than the hour you’ll spend debugging a deploy error.

Step 3 — Upload it

Once you’re happy with what’s in the Change Set, hit Upload.

That’s it for this side. Salesforce establishes a connection, pushes the Change Set to the destination org’s queue, and you’re done in the source org. Nothing has deployed yet. Nothing has changed in production. You’ve just moved the box to the loading dock.

Step 4 — Deploy in the destination org

Switch orgs. Go to Setup, find Inbound Change Sets. Your Change Set should be sitting there.

Click Deploy. You’ll get a wizard — review the component list one more time here, not because you’ve forgotten, but because catching something at this stage is still free.

Then — and this is the step people skip when they’re in a hurry — run Validation before you actually deploy. This does a dry run. It checks for errors, runs test classes, surfaces dependency issues, all without touching anything in production. If something’s wrong, you find out now instead of mid-deployment.

Fix whatever comes up. Re-validate if needed. Then deploy for real.

Step 5 — Stay and watch

Salesforce gives you a deployment status page. Don’t close it and go make coffee.

Errors show up fast. If something’s red, the error message is usually specific enough to tell you exactly what happened. Read it. Don’t just retry the deploy hoping the problem resolves itself — it won’t.

Things I’d tell a junior admin before their first deployment

Do it at a low-traffic time. Most orgs have patterns — certain teams are heavy users between 9 and 11am, or there’s a Monday reporting run that can’t be interrupted. Figure out your org’s quiet window and use it. Not because deployments always cause visible disruption, but because when something does go wrong, you want as few people actively working as possible.

Back up your metadata. Before anything major, export via Workbench or the Salesforce CLI. It feels unnecessary until you need it, and then you’re very glad you have it.

Don’t guess at dependencies. I’ve seen people try to “figure it out from the error” after a failed deployment. That works, eventually, but you’ll cycle through 3–4 failed attempts before you’ve reconstructed the full dependency tree. Map it before you upload. It’s genuinely faster.

Validation failures are information, not obstacles. If you run validation and something fails, that’s the tool doing exactly what it’s supposed to do. Read the message. Often it’s pointing directly at a missing component or a test class asserting something that’s now wrong in the target org.

Where this fits vs. other deployment approaches

Change Sets are a no-DevOps-required option. They work through the UI, they don’t need CLI access or a version control setup, and most experienced admins already know how to use them.

That said — they’re not the right tool for every situation. If you’re managing complex changes across multiple developers working in parallel, or if you need proper version control and rollback history, you’re probably looking at Salesforce DX with Git integration. That’s a different conversation.

For a team with one or two admins, a production org, and a sandbox or two? Change Sets handle it fine. They’re not exciting. They’re not modern. They work.

The thing I actually think about Change Sets

They don’t fail. The process around them does.

The outbound-to-inbound flow is solid. The validation step is solid. What breaks is people skipping validation because they’re confident, or deploying at noon on a Tuesday because the ticket says “urgent,” or stuffing a Change Set with 40 unrelated components because it was easier than sorting them.

Treat it like shipping a physical package. Check what’s inside before you seal the box. Don’t drop it off and immediately leave — wait for confirmation it arrived. And don’t ship during the busiest time at the warehouse.

Originally published at Innostax