4 posts tagged with "Sandboxes"

Deploying between Salesforce environments means moving metadata — objects, fields, Apex, flows, profiles, layouts — from a source to a target. The catch most people hit first: change sets only work between a production org and its own sandboxes, so the moment you need to deploy between two unrelated orgs, a Git branch, or a backup, you have to step up to the Metadata API (via SFDX, the CLI, or a tool like mtdt.io), which deploys between any two connected orgs regardless of type or lineage. This guide walks every source→target combination, when you'd use each, and what won't travel on its own.

There are two kinds of Salesforce admins: the ones who back up their sandboxes, and the ones who haven't been through an accidental refresh yet. A sandbox refresh can't be undone, and as of 2025 Salesforce support no longer recovers an overwritten sandbox — so the only way back is a metadata backup you made before the refresh, which mtdt.io runs on a free, scheduled basis. The day someone refreshes the wrong sandbox — weeks of unreleased config, gone in one click — you find out which kind of admin you are.

You refresh a sandbox, and a day later the tickets start: users can't log in, a workflow blasted a test email to a real customer, an integration is quietly hitting production, and the feature someone spent a week building is gone. All of it is expected — a refresh replaces the sandbox with a fresh copy of its production source, and that one reset touches a lot of things at once.

Here's the complete checklist, grouped and ordered so you handle the dangerous things first.

You spent the afternoon building in a sandbox — a couple of fields on Account, a tweak to a flow, a new permission set, an Apex class. Now you need to move it to the next org. Quick question: what exactly did you change?

Salesforce won't tell you on its own — but a source-tracked org (a scratch org, or a sandbox with source tracking enabled) already records every metadata change you make. mtdt.io's Source Tracking reads that log: start a Record Session, build normally, and it lists every component you touched by name — ready to retrieve, download, deploy, or open as a pull request, no CLI required. Without it, you rebuild the list from memory, click through Setup hunting for every component, and hope you didn't miss the one field that quietly breaks everything downstream.