Salesforce Sandbox Types Explained: Developer, Developer Pro, Partial Copy & Full

TL;DR

• Four sandbox types: Developer, Developer Pro, Partial Copy, and Full. Each trades cost against fidelity to production.
• Developer/Developer Pro = metadata only. Partial Copy / Full = metadata + data.
• Refresh cadence is the killer constraint: Full sandboxes refresh every 29 days; Partial every 5; Dev/Dev Pro every 1 day.
• 2026 strategy: Dev for individuals, Partial for QA, Full for UAT and final pre-prod. Data 360 has its own sandbox namespace.

If you've been building on Salesforce for a while, you have an opinion about which sandbox types you need. If you're new, the choices feel arbitrary. This guide is the canonical reference: what each sandbox actually contains, what it costs, when to refresh, when each is the right choice, and how this all changes in a Data 360 world.

The four types — at a glance

Two non-obvious facts:

1. All sandboxes include all metadata — Apex, Flows, fields, layouts, profiles, permissions. The difference is whether they include data.
2. Refresh cadence is per-sandbox, not per-org. You can refresh your Dev sandbox today and your Full sandbox in a week — they're independent.

When to use each

Developer

The smallest, fastest, cheapest. Each developer or admin gets one. Use for:

• Trying out a new field or Flow without affecting the team.
• Spike work where you'll throw away the code anyway.
• Personal Trailhead practice.

What it doesn't have: production data. Not even a sample.

Developer Pro

10× the storage of Developer. Use when:

• A small team is collaborating on a feature without prod data.
• You need to build out integration test fixtures that don't fit in a Developer org.
• Multiple admins on one branch of work.

Same "no production data" rule. You import test data manually.

Partial Copy

The first type that includes data — but only a sample, governed by a sandbox template. The template tells Salesforce: "from each object, copy at most N records, possibly filtered by criteria."

Use Partial Copy for:

• QA and regression testing where realistic-looking data matters.
• Pre-flighting reports with a representative dataset.
• Integration testing with a manageable data volume.

The 5-day refresh cadence is what makes Partial usable for active QA — you can re-baseline weekly.

Full

A complete copy of production: every record, every file, every Chatter post, every field history row. Use for:

• UAT — business users validate against real data.
• Performance testing — you can't predict prod behavior on a 100K-record sample.
• Pre-launch dry runs.
• Recovery rehearsals.

The 29-day refresh cadence forces you to plan UAT timing carefully. If you blow your refresh window, you wait nearly a month.

Sandbox templates (Partial + Full)

A sandbox template controls which objects come over and how many records. Without a template:

• Partial Copy: pulls a default sample of every standard object, configurable percentages.
• Full: pulls everything (this is the point of Full).

With a template, you specify:

• Which objects to include (skip giant log/audit objects you don't need).
• Filter criteria (e.g., "only Accounts where Industry = 'Software'").
• Master object inclusion (a child object's parent comes along automatically).

Templates are the only way to make Partial Copy useful — without one, the sample distribution often misses the records you actually need to test.

Data masking

Critical for any sandbox containing production data (Partial or Full).

Salesforce ships Sandbox Anonymization as part of Shield. It can:

• Replace email addresses with format-preserving fakes (real.user@company.com → tx2bp1@example.com).
• Replace phone numbers, names, and any custom field with regex-defined patterns.
• Run automatically on every refresh.

Without masking, your Full sandbox is a high-value target — production-equivalent data with weaker access controls than prod itself. If you handle PII, masking is non-optional.

The 2026 refresh strategy

The most common pattern in production-grade orgs:

1. Developer sandboxes: refreshed only when the developer needs a clean start. Often once a quarter.
2. Developer Pro sandboxes: refreshed at the start of every 2-week sprint.
3. Partial Copy: refreshed every Monday. QA owns the schedule.
4. Full sandbox: refreshed at the start of UAT for each major release. Locked during UAT.

If you're doing release management with DevOps Center or any pipeline tool, the refresh schedule maps directly to your environment list:

• dev-1 through dev-N → individual Developer sandboxes
• int → Developer Pro (continuous integration target)
• qa → Partial Copy
• uat → Full
• prod → Production

Data 360 sandboxes (the new piece)

Since Data 360 shipped, Data Cloud has its own sandbox space. A Salesforce sandbox refresh does not automatically refresh Data Cloud's data streams, identity resolution rules, or calculated insights — those are separate.

Data 360 sandbox modes:

• Dev sandbox — Data 360 metadata only (data streams, DMOs, CIs as configured), no records.
• Test sandbox — sample data ingested, suitable for QA on activations.
• Production-replica sandbox — full Data Cloud copy, used sparingly because it's expensive.

The 2026 best practice: separate Data Cloud refresh from CRM sandbox refresh. They have different cadences and different stakeholders.

Deployment paths between sandboxes

The metadata flow most teams use:

• Dev → Int: Change Sets for one-off, DevOps Center or git-based for the team.
• Int → QA: version-controlled deployment of approved metadata.
• QA → UAT: same pipeline; UAT is just QA with full data.
• UAT → Prod: the gated release. Often manual approval + scheduled deploy.

The opposite direction — prod → sandbox — happens via refresh, not deployment. You don't deploy data; you refresh it.

Common mistakes

• Doing development in production. Costly mistake; introduces real risk. Even one-line metadata fixes should go through at least one sandbox.
• Skipping Full sandbox UAT. "Partial is good enough" — until you ship and discover a corner-case data shape that broke Apex in prod.
• Letting sandboxes drift. A Full sandbox you never refresh is more dangerous than no sandbox — your tests pass against stale data while prod drifts.
• No naming convention. "TestSandbox", "Test_Sandbox", "QA1", "QA-1" — a year in, no one knows which is which. Pick a convention day one.
• Treating Data Cloud as if it travels with the sandbox refresh. It doesn't.
• Deploying Apex without test classes that pass in the destination sandbox. They run again on deployment, on the destination's data shape.

Frequently asked questions

How many sandboxes do I get? Depends on edition. Enterprise typically includes 1 Full + 5 Partial + 25 Developer Pro + lots of Developer. Unlimited is more generous. Above defaults are purchasable add-ons.

Can I share sandboxes across orgs? No. Sandboxes belong to one production org. Cross-org sharing is via packaging, not sandbox sharing.

How long does a Full refresh take? 4–48 hours depending on data volume. Plan accordingly.

What's the cost difference? Sandboxes are usually included in your contract. The cost is time + risk of refresh management, not direct dollars (until you exceed the bundle).

Does Agentforce work in sandboxes? Yes — but conversation usage in sandboxes is metered against a separate sandbox quota, not your prod conversation budget. Test agent flows in sandbox first.

What's the relationship to scratch orgs? Scratch orgs are short-lived, source-driven environments for SFDX-style development. Sandboxes are persistent. Both have their place; neither replaces the other.

What to read next

• Sandbox, Change Set, DevOps Center — the dictionary entries.
• Data Cloud Is Now Data 360 — the data-side of the sandbox story.
• Flow vs Apex — what you'll be deploying through these sandboxes.

If you only do one thing: write down your team's intended sandbox + refresh cadence on a single page and pin it. Most environment chaos comes from "we'll figure it out" turning into never figuring it out.