Salesforce Sandbox Strategy: Preview and Non-Preview Best Practices

1. Sandbox Types

1.1 Preview Sandbox

A Preview sandbox runs the upcoming Salesforce release before Production.

Use cases:
• Validate upcoming release changes
• Test integrations and automation against the new release
• Perform release readiness testing

Preview sandboxes are used for validation and preparation only.

1.2 Non-Preview Sandbox

A Non-Preview sandbox runs the same Salesforce release as Production.

Use cases:
• Development
• Integration and QA testing
• User Acceptance Testing (UAT)
• Staging or pre-production validation
• Production deployment promotion

All production-bound deployments must occur through Non-Preview environments.

2. Core Principles

2.1 Version Alignment

Deployments should only occur from environments running:
• The same release version as the target environment, or
• An earlier release version

Deploying from Preview to Non-Preview or Production before Production upgrades can cause compatibility issues.

2.2 Preview Usage

Preview environments are used to:
• Validate upcoming Salesforce releases
• Detect potential issues early
• Prepare for upcoming release changes

Preview sandboxes are not part of the production deployment promotion path.

2.3 Release Readiness Guidance

Preview sandboxes should be used to identify release-related impacts early and validate expected behavior before Production upgrades.

Any required fixes should be implemented and validated in Non-Preview environments so they follow the standard deployment lifecycle.

2.4 Working with Issues Identified in Preview Sandboxes

If an issue is identified during testing in a Preview sandbox, the Preview environment should not be used as the source for deployment.

Recommended approach:

• Detect and validate the issue in the Preview sandbox.
• Identify the required configuration or logic changes.
• Recreate the required changes in a Non-Preview development sandbox.
• Continue validation and deployment through the standard Non-Preview deployment pipeline.

Preview sandboxes are used to identify release-related issues early. Non-Preview environments remain the source for deployable changes.

This approach maintains version alignment and supports a stable deployment process after Production upgrades.

2.5 Non-Preview Usage

Non-Preview environments form the official deployment pipeline to Production.

3. Recommended Sandbox Structure

3.1 Minimum Recommended Structure

The following structure provides a baseline setup to support development, testing, and release readiness activities.

At least one Preview sandbox should be maintained to support release readiness testing and early validation of upcoming Salesforce releases.

Note:
An additional Preview sandbox can be used when separate environments are required for release validation and deployment rehearsal activities.

4. Deployment Lifecycle

All Production deployments should follow this Non-Preview path:

Developer Sandbox (Non-Preview) → Integration / QA (Non-Preview) → UAT (Non-Preview) → Staging / Pre-Production (Non-Preview) → Production

Preview sandboxes operate separately and are used only for validation.

5. Preview Validation Flow

Example usage:

Developer Sandbox → Preview Sandbox (Release Validation)
Optional: Preview Sandbox (Deployment Rehearsal)

No production promotion should occur from Preview environments.

6. Sandbox Refresh Strategy

Preview status is determined by sandbox refresh timing relative to Salesforce release windows.

6.1 General Guidance

• Maintain at least one sandbox refreshed during the preview window if Preview access is required.
• Refresh staging and deployment sandboxes after Production upgrades to maintain version alignment.
• Review Salesforce release schedules in advance and plan refresh activities accordingly.

6.2 Refresh Timing Considerations

Large sandbox refreshes, such as Full Copy sandboxes, may require extended processing time depending on Production data volume and system load.

To reduce the risk of refresh interruption:
• Avoid initiating Full Copy sandbox refreshes close to scheduled Production release upgrades.
• Allow sufficient time for refresh completion before planned release maintenance windows.
• Verify upcoming instance maintenance or release upgrade dates before starting large refresh operations.

If a Production upgrade occurs while a sandbox refresh is in progress, the refresh process may fail and require re-initiation.

Planning refresh activities outside of release upgrade windows helps ensure successful completion and reduces operational impact.

7. Sandbox Planning Guidance

Recommended planning ratio:
Preview : Non-Preview ≈ 1 : 4–8

Examples:
• 5 sandboxes → 1 Preview
• 10 sandboxes → 1–2 Preview
• 20 sandboxes → 2 Preview

More than two Preview sandboxes typically adds operational complexity without proportional benefit.

8. Governance Recommendations

To support stable deployments:
• Use version control
• Document environment ownership
• Use deployment checklists
• Implement automated testing where possible
• Align release planning with Salesforce release cycles

9. Summary of Best Practices

• Maintain at least one Preview sandbox per release cycle.
• Use Preview sandboxes for release validation and release readiness testing.
• Keep all production deployment paths within Non-Preview environments.
• Do not deploy from Preview to Non-Preview or Production before Production upgrades.
• Maintain clear environment roles and refresh planning.