Salesforce delivers 3 major platform releases each year: Spring, Summer, and Winter. Some products also receive monthly updates, so release work can’t be treated as a brief task that starts a few days before production changes. Teams that skip early review often discover broken automation, changed permissions, confusing page behavior, or user questions after the release is already live. Salesforce’s release preparation guidance recommends testing critical use cases in a sandbox because each org has its own configuration and dependencies.
A steady release process gives admins and business owners enough time to identify impact, assign work, test key processes, and prepare users. It also creates a record of what changed and why. The steps below show how to manage all 3 releases through one repeatable cycle.
Step 1: Establish the release calendar and ownership model
Start by locating the upgrade dates for each Salesforce instance and working backward from production. Salesforce usually delivers Spring in February, Summer in June, and Winter in October, though the exact weekend depends on the instance. Add the sandbox preview window, code freeze, user acceptance testing, training, production validation, and review meeting to one shared calendar. Each date needs a named owner and a clear output.
Assign decision rights before anyone reviews release notes. The product owner confirms business priorities, while the admin or technical lead checks configuration impact. Process owners validate affected workflows, and security staff review changes to access or data handling. A defined Salesforce Managed Services model can hold these roles together when internal teams can’t run the cycle alongside daily support work.
Step 2: Record the current state before assessing new features
A release review needs an accurate baseline. Document active clouds, installed packages, custom objects, flows, Apex code, integrations, permission sets, reports, dashboards, and known defects. Add the business processes that depend on each component, including lead routing, quote approval, case handling, billing handoffs, and customer communications. This map separates release risk from existing issues.
The baseline should also include recent performance measures. Record ticket volume, failed automation, integration errors, login issues, and adoption by user group. These figures give the post-release review something concrete to compare against. Without them, the team can confirm deployment, but it can’t show the effect on daily work.
Step 3: Filter the release notes by business impact
Reading every release note with the same level of attention wastes time and hides the changes that matter. Sort each item into 4 groups: automatic changes, required actions, optional features, and items with no current relevance. Connect each relevant item to an affected process, owner, user group, and test case. This turns a large document into a controlled work queue.
Use Salesforce Managed Solutions support where the review requires skills across administration, development, integrations, or security. The provider should explain why an item matters and what could break. Business owners can then approve work based on risk and value.
Step 4: Protect the sandbox preview and test in the right order
Salesforce says the sandbox preview normally begins about 4 to 6 weeks before the production upgrade. The official sandbox preview guidance also warns that refreshing a sandbox during the preview period can move it to a non-preview instance. Confirm sandbox placement before the cutoff date and avoid an unnecessary refresh that removes early access. This single calendar check protects the time needed for testing.
Test in dependency order. Start with login, permissions, integrations, and scheduled jobs because failures there can block later tests. Continue with high-volume processes and automation, then review page layouts, reports, and optional features. Record the expected result, actual result, evidence, owner, and defect status so approvals don’t depend on memory.
Step 5: Control changes, access, and rollback decisions
Every release-related change needs a path from approval to production. Separate mandatory fixes from optional feature adoption, then set a code and configuration freeze before final testing. Require peer review for code, flows, permission changes, and integration updates. Each production item also needs a rollback or containment plan that states what the team will do if validation fails.
Security checks belong inside the release plan. The NIST Cybersecurity Framework 2.0 organizes risk work around 6 functions and links to more than 50 cybersecurity documents. Its Govern function supports named decision makers and clear policy ownership. Apply that structure to privileged access, connected apps, API users, and emergency changes.
A Salesforce Managed Company should provide visible records for approvals, tests, deployments, and incidents. Ask who can change production and how emergency work is documented. Clear answers reduce dependence on one administrator.
Step 6: Prepare users before the production weekend
A release can pass technical testing and still disrupt work when users aren’t prepared. Identify changes that affect navigation, field behavior, reports, approvals, mobile use, or required steps. Send role-based guidance that explains what will change, when it will appear, and where users should report a problem. Keep the message focused on user actions.
Training depth should match the effect. A small visual change may need a brief notice, while a changed approval path may need a demonstration and updated job aid. Support teams should receive known issues and escalation instructions before users see the release. This preparation cuts duplicate tickets.
Step 7: Validate production and review the full cycle
Production validation should begin as soon as the upgrade window closes. Run a short set of critical tests for authentication, integrations, automation, record creation, approvals, and customer-facing functions. Compare results with sandbox evidence and assign a business impact level. Keep optional feature activation separate until the production baseline is stable.
The service review should examine the process as well as the platform. ISO/IEC 20000-1:2018, confirmed as current in 2023, covers planning, transition, delivery, measurement, and service improvement. Use that logic to review defects, emergency changes, test coverage, response times, and unresolved actions. Each lesson should become a calendar change, test update, or backlog item before the next release.
A Salesforce Managed Services Partner should report outcomes in terms business owners can use. Useful measures include release defects, failed changes, backlog age, user adoption, and recovery time. Review trends across all 3 annual releases because one successful weekend doesn’t prove the process is dependable.
Final release readiness check
The release is ready when every critical process has an owner, test evidence, approval status, and response plan. The team should know which sandbox received the preview, which changes are automatic, and which production items can be reversed or contained. Users and support staff should receive the right guidance before the upgrade, and the review meeting should already be on the calendar.
Run this check before each Spring, Summer, and Winter release. A repeatable process turns 3 major updates from separate emergencies into scheduled service work. It also gives leaders evidence that Salesforce changes are being assessed, tested, communicated, and reviewed through the same controlled cycle.
Frequently asked questions
How early should Salesforce release planning begin?
Planning should begin when Salesforce publishes the instance dates and sandbox preview instructions. The working calendar should be ready before the 4 to 6 week preview period starts. That gives the team time to protect the correct sandbox, review relevant notes, assign owners, and prepare test cases without compressing the work into the final week.
Does every Salesforce release require new feature adoption?
Each release contains automatic changes, required actions, and optional features that may have different value for each org. Review business impact first, then adopt optional features only when they solve a defined problem and the team has time to test them. Deferring a feature is a valid decision when current priorities or dependencies make adoption unsafe.
Which processes should be tested first?
Test the processes that can block access or stop core operations. Authentication, permissions, integrations, scheduled jobs, and high-volume automation usually come before cosmetic changes. The exact order should follow business impact, transaction volume, and the number of downstream dependencies. Keep a smaller production validation set for the release weekend.
What should a release readiness report contain?
The report should show the release date, affected processes, owners, testing status, open defects, security actions, user communication, and rollback plans. It should also identify optional features that were accepted, deferred, or rejected. Business owners need a clear view of remaining risk before approval.
How should release performance be measured?
Measure both technical stability and operating effect. Track failed changes, release-related incidents, response time, repeated defects, test coverage, adoption, and backlog age. Compare the results with the baseline recorded before the release. The review should end with named actions and due dates for the next cycle.
For more info Contact Us : 800–360–1407 or send mail : [email protected] to get a quote
Comments
Log in or sign up to join the conversation.