Environment Strategy

Environment strategy underpins a well-managed Salesforce development lifecycle. The topology must balance developer productivity, testing rigor, release safety, and cost. The wrong strategy causes bottlenecks, data leaks, deployment failures, and developer frustration.

Sandbox Types

Salesforce offers four sandbox types, each with different capabilities and limitations. Choose the right mix based on team size, data needs, and release cadence.

Feature	Developer	Developer Pro	Partial Copy	Full Copy
Metadata	Full copy	Full copy	Full copy	Full copy
Data	None	None	Sample (template)	Full copy
Storage	200 MB	1 GB (configurable storage upgrades available since Spring ‘25)	5 GB	Same as production
Refresh cycle	1 day	1 day	5 days	29 days
Included in	EE, UE, PE	EE, UE, PE	EE, UE, PE	UE, PE
Typical count	Many	Several	2-3	1
Best for	Individual development	Development + unit testing	Integration testing, UAT	Staging, performance testing

Developer Sandbox

Use for: Individual feature development, POC work, learning, and experimentation.

Limitations:

No data. Developers must create test data manually or use scripts.
200 MB storage, insufficient for large data testing
Cannot test data-dependent features (reports, dashboards with live data)

Developer Pro Sandbox

Use for: Development work requiring more storage, unit testing with moderate data volumes.

Limitations:

Still no production data; data must be manually created
1 GB storage, better than Developer but still limited
Not suitable for volume testing

Partial Copy Sandbox

Use for: Integration testing, QA, UAT. Uses a sandbox template to copy a sample of production data.

Key considerations:

Sandbox template defines which objects and records to include (up to 10K records per object)
Template design matters. Include enough data to test but not so much that it slows refresh.
Data is a snapshot, not a live sync. It becomes stale after refresh.
Sensitive data may be included unless data masking is in place

Full Copy Sandbox

Use for: Staging, performance testing, final UAT, training. Full copy of production metadata and data.

Key considerations:

29-day refresh cycle. Plan carefully; there is no quick reset.
Full production data includes PII and sensitive data, so data masking is essential
Storage matches production, which gets expensive if production is large
Performance testing is only valid here (data volume affects query performance)

Environment Topology

Standard Enterprise Topology

Figure 1. SIT is the merge point where individual developer streams come together for the first time. Separating SIT from UAT ensures that business users accept a stable build, not one still receiving in-flight developer changes.

Environment Purpose Matrix

Environment	Purpose	Data	Who Uses It	Refresh Cadence
Dev Sandboxes	Feature development	Test data scripts	Developers	As needed (daily capable)
Scratch Orgs	CI/CD validation, feature isolation	Test data scripts	CI/CD pipeline	Per feature branch
SIT (System Integration Test)	Integration testing, cross-team validation	Partial copy (template)	Dev team, QA	Per sprint/release
UAT	Business user acceptance testing	Partial copy (template)	Business users, BA	Per release
Staging	Pre-production validation, performance	Full copy	Release team, QA	Per release (29-day min)
Production	Live environment	Real data	All users	N/A

Scratch Orgs

Scratch orgs are ephemeral, fully configurable environments created from a definition file. They are central to modern Salesforce DX development.

When to Use Scratch Orgs

Use Scratch Orgs	Use Sandboxes
CI/CD pipeline validation	Integration testing with real data
Feature branch isolation	UAT with business users
Package development	Performance testing
Automated testing	Training environments
Short-lived, disposable environments	Long-lived, persistent environments

Scratch Org Definition File

The project-scratch-def.json defines the scratch org’s shape:

{
  "orgName": "CTA Study Scratch Org",
  "edition": "Enterprise",
  "features": ["Communities", "ServiceCloud"],
  "settings": {
    "lightningExperienceSettings": {
      "enableS1DesktopEnabled": true
    },
    "securitySettings": {
      "passwordPolicies": {
        "enableSetPasswordInApi": true
      }
    }
  }
}

DevHub Configuration

DevHub is the production org (or business org) that manages scratch org creation
Enable it in Setup > Dev Hub
Scratch orgs count against the DevHub’s active scratch org limit. Limits by edition: Performance/Unlimited (100 active, 200 daily), Enterprise (40 active, 80 daily), Developer (3 active, 6 daily)
A namespace can be linked to DevHub for package development

Sandbox Refresh Lifecycle

The full refresh lifecycle determines environment availability and disruption windows.

Figure 2. The SandboxPostCopy interface is the only reliable way to automate post-refresh setup, because manual checklists get skipped under time pressure. Verifying email deliverability remains at ‘System email only’ (the default since Spring ‘13) is critical for Partial Copy and Full Copy sandboxes that contain real customer email addresses.

Salesforce DX Environment Flow

Modern Salesforce DX development uses DevHub and scratch orgs alongside traditional sandboxes. The diagram below shows how these components interact.

Figure 3. Scratch orgs are defined entirely by source (the scratch-def.json and the project metadata), so any developer can recreate an identical environment in minutes. CI scratch orgs use a 1-day TTL to reduce active org count consumption against DevHub limits.

Source Tracking

Source tracking bridges local project files and the scratch org or sandbox:

sf project deploy start pushes local changes to the org
sf project retrieve start pulls org changes to the local project
Source tracking (enabled by default in scratch orgs; also supported in Developer and Developer Pro sandboxes when the associated production org has source tracking enabled) detects which files changed on either side, enabling bidirectional sync
Conflict detection flags cases where both local and org have changed the same metadata component

Refresh Planning

Refresh Cadence Best Practices

Environment	Recommended Cadence	Trigger
Developer Sandboxes	As needed	When sandbox drifts too far from production metadata
SIT	Per release/sprint	Start of each sprint or release cycle
UAT	Per release	Before each UAT cycle begins
Staging	Per release (if possible)	Before final pre-production validation

Pre-Refresh Checklist

Notify teams: All users of the sandbox must know it is being refreshed
Export configuration: Any sandbox-specific configuration that is not in source control
Document manual steps: Anything that must be re-done after refresh
Verify source control: Ensure all in-progress work is committed
Schedule appropriately: Full Copy sandboxes take hours to days

Post-Refresh Activities

Post-copy scripts automate setup that must happen after every sandbox refresh. Implement them using the SandboxPostCopy interface in Apex:

Common post-copy tasks:

Update integration endpoint URLs (sandbox vs production)
Mask or anonymize sensitive data (PII, financial data)
Verify email deliverability is set to ‘System email only’ (default since Spring ‘13, but verify after every refresh)
Update custom settings with sandbox-specific values
Deactivate or reassign workflow email alerts
Create test users with appropriate profiles
Update Named Credential endpoints

global class PostCopySetup implements SandboxPostCopy {
    global void runApexClass(SandboxContext context) {
        // Mask PII data
        // Update integration endpoints
        // Verify email deliverability is 'System email only'
        // Create test data
    }
}

Data Masking

Data masking is required for any environment that copies production data (Partial Copy, Full Copy).

What to Mask

Data Category	Examples	Masking Approach
PII	Names, emails, phone numbers	Randomize or replace with fake data
Financial	Credit card numbers, bank accounts	Replace with test numbers
Health	Medical records, diagnoses	Remove or generalize
Authentication	Passwords, tokens, API keys	Reset or remove
Business sensitive	Revenue, pricing, contracts	Generalize or replace

Data Masking Architecture

Figure 4. Three masking strategies serve different scenarios: Salesforce Data Mask handles bulk field-level anonymization after refresh, SandboxPostCopy Apex covers targeted programmatic masking, and template filtering simply excludes objects too sensitive to copy at all.

Masking Strategies

Salesforce Data Mask: Native Salesforce managed package add-on installed in production with masking rules configured there. After each sandbox refresh, Data Mask is run manually or via API in the sandbox to apply field-level masking with pattern matching, random generation, and deletion. It does not run automatically during sandbox creation. Preferred for compliance.
Post-copy Apex script: Masks data programmatically after refresh using the SandboxPostCopy interface. Limited by governor limits and execution time, so it suits targeted masking but not full-org sweeps.
Third-party tools: Informatica, OwnBackup, Provar. These offer more sophisticated masking rules, cross-object consistency, and referential integrity.
Sandbox template filtering: Excludes sensitive objects entirely from Partial Copy templates. Simplest approach but limits testing realism.

Sandbox Naming Conventions

Consistent naming reduces confusion and prevents deployment errors:

Pattern	Example	Description
`{Purpose}`	`DEV`, `SIT`, `UAT`, `STAGE`	Simple, clear purpose
`{Purpose}-{Team}`	`DEV-SALES`, `DEV-SERVICE`	Multi-team environments
`{Purpose}-{Release}`	`UAT-R2024Q4`	Release-specific environments
`{Purpose}-{Feature}`	`DEV-CPQ-MIGRATION`	Feature-specific development