Environment Strategy

Environment strategy is the backbone of a well-managed Salesforce development lifecycle. A CTA must design an environment topology that balances 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. The CTA must 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	UE, PE (limited)	UE, PE (limited)	UE, PE (limited)
Typical count	Many	Several	2-3	1
Best for	Individual development	Development + unit testing	Integration testing, UAT	Staging, performance testing

Sandbox Limits by Edition

Enterprise Edition includes 1 Developer sandbox (additional sandboxes can be purchased). Unlimited Edition includes 100 Developer, 5 Developer Pro, 5 Partial Copy, and 1 Full Copy. Performance Edition is similar to Unlimited. Additional sandboxes can be purchased. Always verify current limits with the customer’s contract.

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 is critical — 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 you implement data masking

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, you cannot reset quickly
Full production data includes PII and sensitive data — data masking is essential
Storage matches production — expensive if production is large
Performance testing is only valid here (data volume affects query performance)

Environment Topology

Standard Enterprise Topology

flowchart LR
    subgraph Development
        DEV1[Dev Sandbox 1<br/>Developer]
        DEV2[Dev Sandbox 2<br/>Developer]
        DEV3[Dev Sandbox 3<br/>Developer]
        SCRATCH[Scratch Orgs<br/>CI/CD]
    end

    subgraph Testing
        SIT[SIT Sandbox<br/>Partial Copy]
        UAT[UAT Sandbox<br/>Partial Copy]
    end

    subgraph Staging
        STAGE[Staging Sandbox<br/>Full Copy]
    end

    subgraph Production
        PROD[Production Org]
    end

    DEV1 --> SIT
    DEV2 --> SIT
    DEV3 --> SIT
    SCRATCH --> SIT
    SIT --> UAT
    UAT --> STAGE
    STAGE --> PROD

    style PROD fill:#e76f51,stroke:#c45a3f,color:#fff
    style STAGE fill:#f4a261,stroke:#d4823e,color:#000
    style SIT fill:#4ecdc4,stroke:#3ab5ad,color:#000
    style UAT fill:#4ecdc4,stroke:#3ab5ad,color:#000
    style DEV1 fill:#2d6a4f,stroke:#1b4332,color:#fff
    style DEV2 fill:#2d6a4f,stroke:#1b4332,color:#fff
    style DEV3 fill:#2d6a4f,stroke:#1b4332,color:#fff
    style SCRATCH fill:#2d6a4f,stroke:#1b4332,color:#fff

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 Salesforce 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 DevHub in Setup > Dev Hub
Scratch orgs count against DevHub’s active scratch org limit, which varies by DevHub edition: Performance/Unlimited (80 active, 160 daily), Enterprise (40 active, 80 daily), Developer (6 active, 12 daily)
Namespace can be linked to DevHub for package development

Scratch Org Limits

Scratch orgs expire after a maximum of 30 days (default 7). They cannot be refreshed — they are recreated from source. If your CI/CD pipeline creates many scratch orgs, monitor the daily creation limit. Exceeding it blocks your pipeline.

Sandbox Refresh Lifecycle

Understanding the full refresh lifecycle is critical for planning environment availability and minimizing disruption.

flowchart TD
    A([Refresh Triggered]) --> B[Notify All<br/>Sandbox Users]
    B --> C[Export Sandbox-Specific<br/>Config & Data]
    C --> D[Verify All Work<br/>Committed to Git]
    D --> E{Sandbox Type?}

    E -->|Developer / Dev Pro| F[Metadata-Only<br/>Copy from Prod]
    E -->|Partial Copy| G[Metadata + Template<br/>Data Subset]
    E -->|Full Copy| H[Full Metadata +<br/>Data Clone]

    F --> I[Sandbox Available<br/>Minutes to Hours]
    G --> I
    H --> J[Sandbox Available<br/>Hours to Days]

    I --> K[SandboxPostCopy<br/>Apex Runs]
    J --> K

    K --> L[Mask PII Data]
    L --> M[Update Integration<br/>Endpoints]
    M --> N[Disable Email<br/>Deliverability]
    N --> O[Create Test Users<br/>& Data]
    O --> P[Validate Sandbox<br/>Health]
    P --> Q([Sandbox Ready<br/>for Use])

    style A fill:#4ecdc4,stroke:#3ab5ad,color:#000
    style Q fill:#2d6a4f,stroke:#1b4332,color:#fff
    style K fill:#f4a261,stroke:#d4823e,color:#000
    style L fill:#e76f51,stroke:#c45a3f,color:#fff

Automate Post-Copy Tasks

Never rely on manual steps after a sandbox refresh. Implement the SandboxPostCopy interface in Apex so that endpoint updates, data masking, email disablement, and test user creation happen automatically every time. Manual post-refresh checklists are error-prone and get skipped under time pressure.

Salesforce DX Environment Flow

Modern Salesforce DX development uses DevHub and scratch orgs alongside traditional sandboxes. Understanding how these components interact is essential.

flowchart TD
    subgraph DevHub["DevHub (Production Org)"]
        DH[DevHub Enabled<br/>Manages Scratch Orgs]
        NS[Namespace Registry]
        PKG[Package Creation<br/>& Versioning]
    end

    subgraph Developer["Developer Workstation"]
        CLI[Salesforce CLI<br/>sf commands]
        VCS[Git Repository<br/>Source of Truth]
        DEF[scratch-def.json<br/>Org Shape Definition]
    end

    subgraph Ephemeral["Scratch Orgs (Ephemeral)"]
        SO1[Scratch Org 1<br/>Feature A — 7 day TTL]
        SO2[Scratch Org 2<br/>Feature B — 7 day TTL]
        SO3[CI Scratch Org<br/>Pipeline — 1 day TTL]
    end

    DH -->|Authorizes creation| SO1
    DH -->|Authorizes creation| SO2
    DH -->|Authorizes creation| SO3
    CLI -->|sf org create scratch| SO1
    CLI -->|sf org create scratch| SO2
    CLI -->|sf project deploy start| SO1
    CLI -->|sf project retrieve start| SO2
    VCS <-->|push / pull| CLI
    DEF -->|Defines shape| SO1
    DEF -->|Defines shape| SO2
    PKG -->|sf package install| SO3

    style DH fill:#1a535c,stroke:#0d3b44,color:#fff
    style CLI fill:#2d6a4f,stroke:#1b4332,color:#fff
    style VCS fill:#2d6a4f,stroke:#1b4332,color:#fff
    style SO1 fill:#4ecdc4,stroke:#3ab5ad,color:#000
    style SO2 fill:#4ecdc4,stroke:#3ab5ad,color:#000
    style SO3 fill:#4ecdc4,stroke:#3ab5ad,color:#000

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 local project
Source tracking (enabled by default in scratch orgs and sandboxes) detects which files changed on either side, enabling bidirectional sync
Conflict detection flags when both local and org have changed the same metadata component

Source Tracking Limitations

Source tracking only works with scratch orgs and sandboxes. It does not work with production orgs or Developer Edition orgs. For non-tracked orgs, you must manually specify what to deploy or retrieve using manifest files (package.xml).

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 (post-refresh) scripts automate the setup that must happen after every sandbox refresh. Implement these 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)
Disable email deliverability (prevent test emails to real customers)
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
        // Disable email deliverability
        // Create test data
    }
}

Data Masking

Data masking is essential 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

flowchart LR
    subgraph Production
        PROD_DATA[(Production Data<br/>Contains PII)]
    end

    subgraph Refresh["Sandbox Refresh"]
        COPY[Data Copy<br/>Process]
    end

    subgraph Masking["Masking Layer"]
        direction TB
        DM[Salesforce Data Mask<br/>Native Add-On]
        PC[SandboxPostCopy<br/>Apex Script]
        TF[Template Filtering<br/>Exclude Sensitive Objects]
    end

    subgraph Sandbox["Non-Production Sandbox"]
        SAFE_DATA[(Masked Data<br/>PII Removed)]
    end

    PROD_DATA --> COPY
    COPY --> DM
    COPY --> PC
    COPY --> TF
    DM --> SAFE_DATA
    PC --> SAFE_DATA
    TF --> SAFE_DATA

    style PROD_DATA fill:#e76f51,stroke:#c45a3f,color:#fff
    style SAFE_DATA fill:#2d6a4f,stroke:#1b4332,color:#fff
    style DM fill:#4ecdc4,stroke:#3ab5ad,color:#000
    style PC fill:#4ecdc4,stroke:#3ab5ad,color:#000
    style TF fill:#4ecdc4,stroke:#3ab5ad,color:#000

Masking Strategies

Salesforce Data Mask: Native Salesforce add-on that runs automatically during sandbox creation. Supports field-level masking with pattern matching, random generation, and deletion. Preferred approach for compliance.
Post-copy Apex script: Mask data programmatically after refresh using the SandboxPostCopy interface. Limited by governor limits and execution time — suitable for targeted masking but not full-org sweeps.
Third-party tools: Informatica, OwnBackup, Provar — more sophisticated masking rules, cross-object consistency, and referential integrity.
Sandbox template filtering: Exclude sensitive objects entirely from Partial Copy templates. Simplest approach but limits testing realism.

Compliance Requirement

In regulated industries (healthcare, financial services), failing to mask production data in non-production environments is a compliance violation. HIPAA, PCI-DSS, GDPR, and SOX all have requirements around data in non-production environments. The CTA must address this in the architecture.

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

Email Suffix

Sandbox emails append .{sandboxname} to the user’s email (e.g., user@company.com.dev). Short, clear sandbox names make email addresses manageable. Avoid overly long or cryptic names.