Salesforce Sandbox vs Production Deployment: What Developers Need to Know

6 min read · Salesforce · Sandbox · Metadata Deployment

Deploying Salesforce metadata to the wrong environment — or skipping required test validation — is one of the most common and costly mistakes in Salesforce development. Understanding when to deploy to a sandbox versus production, which test level to use, and what can go wrong at each stage will save you hours of rollback and debugging.

What Is a Salesforce Sandbox?

A Salesforce sandbox is an isolated copy of your production org used for development, testing, and staging. Sandboxes share the same metadata schema as production but contain separate data, allowing you to safely develop and test changes without affecting live users or real records.

Every Salesforce org comes with at least one Developer sandbox. Higher editions include additional sandbox types with more data capacity.

Sandbox Types

Type	Refresh Interval	Storage	Best for
Developer	1 day	200 MB data / 200 MB files	Individual development, quick iteration
Developer Pro	1 day	1 GB data / 1 GB files	Larger dev projects, more complex data needs
Partial Copy	5 days	5 GB	UAT with a representative data sample
Full	29 days	Full production copy	Pre-production staging, performance testing

For most development workflows, a Developer or Developer Pro sandbox is sufficient. Partial Copy and Full sandboxes are valuable when user acceptance testing requires production-like data volumes.

The Deployment Pipeline

A typical Salesforce deployment pipeline moves metadata through a series of environments before reaching production:

Developer sandbox — where individual developers build and test their changes
Integration sandbox — where changes from multiple developers are merged and tested together
UAT / staging sandbox — where business stakeholders validate changes against production-like conditions
Production — the live org

Not every project needs all four stages. Smaller teams often deploy directly from a developer sandbox to production after testing.

Test Levels: The Critical Difference

Every Salesforce metadata deployment runs Apex tests during deployment. The --test-level flag controls which tests run and when they're required.

Test Level	What it runs	Valid for sandbox?	Valid for production?
`NoTestRun`	No tests	Yes	No
`RunSpecifiedTests`	Named test classes only	Yes	Yes, if coverage ≥ 75%
`RunLocalTests`	All non-managed-package tests	Yes	Yes (default for prod)
`RunAllTestsInOrg`	Every test including managed packages	Yes	Yes (slowest)

Production deployments always require at least 75% overall Apex code coverage. If your org falls below this threshold, the deployment will fail regardless of which test level you choose.

Choosing the Right Test Level

Use NoTestRun for rapid iteration during early sandbox development when you're not changing Apex code.
Use RunSpecifiedTests when you know exactly which test classes cover your changes and need faster feedback.
Use RunLocalTests as your default for production — it's the safest and most complete option without the overhead of managed package tests.
Use RunAllTestsInOrg only when debugging coverage issues that might involve managed package interactions.

Common Reasons Deployments Fail

Even well-tested changes can fail in production for reasons that didn't appear in a sandbox:

Missing dependencies — your sandbox has a custom object or field that hasn't been deployed to production yet. The deployment references it, production doesn't have it, deploy fails.
Coverage drops — production may have more Apex code than your sandbox. Adding new untested code can push overall coverage below 75%.
Active validation rules or triggers — production data triggers test failures that never surfaced in a sandbox with synthetic data.
Hard-coded IDs — record type IDs, profile IDs, and custom setting values differ between orgs. Hard-coding sandbox IDs into metadata will break production deployments.

Before every production deployment, do a dry run using sf project deploy validate. This runs the full deployment — including all tests — without actually committing any changes. If it passes, your real deploy will too.

What Actually Gets Deployed

Salesforce metadata deployment covers a wide range of components: Apex classes and triggers, Lightning Web Components and Aura components, custom objects and fields, page layouts, permission sets, flows, reports, dashboards, and more. Anything that's part of your SFDX source directory gets included.

Components that exist in the org but are not in your source directory are left untouched. Deploying is additive and modifying — it does not delete components unless you explicitly include a destructive changes manifest.

Deploying Without the CLI

The standard deployment workflow requires the Salesforce CLI installed locally, terminal access, and authenticated sessions that expire. For teams where developers need to deploy quickly without setting up local tooling, reapd provides a browser-based deployment interface.

Connect your GitHub repository and Salesforce org via OAuth, select your branch and source path, choose a test level, and start the deployment. Live logs stream in real time, and failures are broken down by component — the same information you'd see in a terminal, without opening one.

Both sandbox and production deployments are supported. Saved org connections make it easy to switch between dev, QA, and production environments without re-authenticating each time.

Deploy to sandbox or production from your browser

No local CLI. No terminal. Connect your org and GitHub repo and start deploying in seconds.

Start deploying free →