In this article, we will explore release updates in Salesforce. Whether you are an admin, business analyst, consultant, developer, or architect, it’s important you keep on top of these updates and make sure your Salesforce orgs are prepared in time.
Salesforce has three releases each year: Spring, Summer, and Winter. With each release, Salesforce introduces new release updates and provides an enforcement date for each. If you don’t prepare in time, things could start to error after the enforcement date.
What Is a Release Update?
If you are familiar with Windows or Mac, you are likely to have seen updates from time to time. When the operating system is upgraded from one version to another, it is a little like a major release in Salesforce (Spring, Summer, and Winter).
During this cycle, you may get smaller updates that impact more specific areas, such as your web browser being upgraded or your email client being updated. In Salesforce terms, this is a little like the release update mechanism.
Unlike other software updates, these are usually announced far in advance. You need to prepare your Salesforce org for any potential impact or changes.
Release updates can be changed or pushed back, so make sure to keep an eye on the Salesforce Release Notes to stay up to date. You can also find the details from Release Updates in Salesforce Setup.
Release Update Process
As release updates follow a predictable process, I’ve devised a process flow you can use to prepare your Salesforce orgs in a way that ensures you are prepared.
If you have specific processes around changes in your Salesforce org and release management, then this may vary for your specific organisation.
Am I Using This Feature?
The first step in this process is to ascertain whether you are using this particular feature. If you lean into a developer skill set, you can use a tool such as Visual Studio Code to search for references within the Salesforce Metadata to determine where the feature is used.
There are other ways to determine if a feature is being used.
For example: If an update is related to Service Cloud Voice and you do not have a licence for this feature, then it’s safe to assume that the release update will have no impact.
Where Is This Feature Used?
Once you’ve defined where this feature is used, it’s time to start creating a list of where it’s used to ascertain what needs to be updated and then tested.
If you’ve used Visual Studio Code already in the previous steps, you may already have explicit references that will be impacted by this update!
If you are compiling this list manually, then be sure to keep thorough notes, as these will help you later.
If you have any managed packages installed, then you may not be able to find references in these packages. Be sure to double-check with the package provider to ensure that functionality is not impacted by the release update.
What Changes Are Needed?
Once you’ve completed the previous steps, you’ll likely have a list of items that need to be updated. This step is about translating this list into system changes that need to be made as a result.
For example: If Salesforce is retiring a standard field that is used in a number of flows, those references will need to be removed.
Depending on your own skill set, you may need technical guidance here. As part of this, you may need to estimate the effort to make these changes and allocate that effort to a particular development sprint, but this will vary between organisations.
Implement Changes in Initial Sandbox
In order to comply with the upcoming change, you will need to refactor any references. These will need to comply with the new update or to no longer rely on something that is retired.
You should develop these changes in the sandbox furthest away from your Production environment initially. The structure of your sandboxes and the order in which you deploy changes between them will vary based on your organisation.
In the below sandbox structure, Tom Dev is furthest away from the Production.
Test Release Update in Initial Sandbox
Good news! For the majority of release updates, Salesforce provides the ability to “Enable Test Run”. This is where you can test the update before Salesforce enforces it.
If the release update does not support a test run, refer to the guidance provided by Salesforce on how to test that specific update.
Test, Deploy, and Repeat
It’s important that this is done at the back of your sandbox pipeline so that the changes are implemented throughout your sandboxes.
This will involve testing the changes in the sandbox in line with the new update. If testing is successful, deploy to the next environment.
Implement Changes in Production
Once you’ve made the necessary supporting changes and tested the update in your sandboxes, it’s time to plan deployment to Production.
To avoid any user disruption, plan for outside of working hours. If things don’t go according to plan, be sure to have a backup plan so things can be fixed before users are next online.
Test Release Update in Production
Immediately following your deployment, enable and test the release update in Production.
This way, you can test changes outside of normal working hours and have time to disable the update and any revert changes before users’ next login in case of issues.
Summary
It may seem daunting when having to deal with Salesforce release updates the first few times! Once you’ve followed this guide, it’ll become a simple, repeatable process, and you’ll be able to breeze through these updates with ease.
Don’t forget to check out the latest article for specifics on upcoming release updates and how to prepare.