Seasonal releases, sandbox preview and release updates
How to de-risk the three seasonal releases: plan backward from published upgrade dates, place sandboxes on preview or non-preview instances around the cutoff (Release Type, Request Non-Preview, clones), handle package uploads during the preview window, test release updates before sandbox test periods end, and turn release notes into communication and phased rollout.
Given a customer scenario involving a new Salesforce release (Summer, Winter, Spring), recommend the appropriate strategy to mitigate risks.
~8 min read · 9 practice questions ·
What the exam expects
- Build a release readiness plan that works backward from the published sandbox and production upgrade dates, with regression testing on a preview sandbox.
- Decide whether each sandbox should be on a preview or non-preview instance, and what to do before or after the cutoff: refresh, Request Non-Preview, or clone.
- Predict which orgs can install a package uploaded during the preview window.
- Schedule release update test runs so sandbox testing finishes before its test period ends.
- Use release notes Feature Impact filters, super users and phased rollout to communicate changes.
Key terms: preview instance (sandboxes here get the next release several weeks before production; Help says 6 weeks, Trailhead says 4-6); non-preview instance (sandboxes here stay on the current release until production upgrades); cutoff date (the last moment a create or refresh can land on a preview instance); Release Type (the Sandboxes page column showing preview or non-preview); release update (a Salesforce change to existing behaviour with a Complete Steps By date and an optional test run).
Key facts
- Detail
- Three a year (Spring, Summer, Winter); upgrades automatic for all customers
- Detail
- Help article: 6-week window; Trailhead unit: approximately 4-6 weeks. Teach "about six weeks" and no release-specific dates
- Detail
- Usually the day before the preview starts
- Detail
- Lands on a non-preview instance, current release
- Detail
- Org permission from Customer Support; before the cutoff
- Detail
- Same release as the sandbox being cloned
- Detail
- Release Type column on the production Sandboxes page, or the Sandbox Preview Guide
- Detail
- Enables the update immediately; sandbox test periods may end before Complete Steps By
- Detail
- Enabled for Users finds Quick Wins; Admins must Enable finds Low-hanging Fruit
Sources for this section (5)
- Release Processtrailhead.salesforce.com (opens in a new tab)
- Sandbox Preview Instructionshelp.salesforce.com (opens in a new tab)
- Sandbox Preview unittrailhead.salesforce.com (opens in a new tab)
- Release Updateshelp.salesforce.com (opens in a new tab)
- New Features Enablementtrailhead.salesforce.com (opens in a new tab)
- Why must a sandbox refresh meant for the preview be requested well before the cutoff?
- When does a clone request land on the same release as its source sandbox?
- Where does an architect check whether each sandbox is preview or non-preview?
- Why run Low-hanging Fruit features past super users before rollout?
The questions are free to read. Answers with their sources and self-grading are included with the pack.
Keep reading with the Platform Development Lifecycle and Deployment Architect pack
- Core concepts
- Exam traps
- Worked scenario
The pack includes:
- All 26 lessons of the Platform Development Lifecycle and Deployment Architect guide, with reading progress
- Interactive decision walks and step-by-step sequence steppers
- Inline practice questions and one-click topic practice (9 questions for this lesson)
- An official source cited for every claim
- An AI tutor that answers from the guide
- Unlimited timed practice exams