Release Updates
A Release Update is a platform change that Salesforce plans to enforce on your org, surfaced in a dedicated Setup page so admins can review it, test it, and prepare before it becomes mandatory.
Definition
A Release Update is a platform change that Salesforce plans to enforce on your org, surfaced in a dedicated Setup page so admins can review it, test it, and prepare before it becomes mandatory. Each entry carries a short description, an impact assessment, an enforcement date, and usually a Test Run action that simulates the changed behavior in your live org without committing to it.
The Release Updates page replaced the older Critical Updates console and became the single place where breaking or behavior changing platform updates are tracked. Salesforce ships three major releases a year (Spring, Summer, Winter), and updates are typically introduced in one release and enforced one or two releases later, which gives teams a known window to test and react.
How Release Updates move from announced to enforced
What a Release Update actually is
A Release Update is not a new feature you opt into. It is a change to existing behavior that Salesforce intends to turn on for every org, whether you act or not. The Release Updates page in Setup collects these in one list so nothing slips past you. Each item shows what is changing, why Salesforce is making the change, and the release in which enforcement happens. Typical examples include tightening a security default, changing how a piece of Apex or Flow handles an edge case, retiring a legacy setting, or requiring a stricter sharing behavior. Because the change is coming regardless, the page frames your job as preparation rather than decision. You read the update, judge whether it touches your configuration or code, and test it before the date arrives. Salesforce built this page so admins stop hunting through release notes for the items that can break production. The list is scoped to your org, so you generally see updates that are relevant to features you actually use, which keeps the review focused instead of overwhelming.
From Critical Updates to Release Updates
Older orgs managed these changes through a feature called Critical Updates, shown in a separate console. Salesforce consolidated that experience into Release Updates so every behavior change, security tightening, and enforcement deadline lives in one consistent place inside Setup. The move also standardized the language. Instead of scattered critical update notices, you get a uniform card per item with a description, an enforcement release, and a Test Run path. If you maintain an org that has been around for several releases, you may still hear the old Critical Updates name in documentation or from long time admins, but the modern surface is Release Updates. The consolidation matters for a practical reason. When all platform changes share one inbox, it is far easier to build a repeatable habit around release prep. You open one page each cycle rather than reconciling release notes, critical update banners, and product notification emails. The underlying changes are the same kind of thing they always were, but the tracking is centralized and the workflow is predictable.
The announce, test, enforce timeline
Release Updates follow a rhythm tied to the three annual releases. An update is usually announced in one release, made available to test during that window, and then enforced in a later release, often one or two cycles out. That gap is the whole point. It gives you time to find the update, test it, and fix anything that fails before the change becomes permanent. Each item shows its enforcement release and date, so you can plan backward from the deadline. Sandboxes are upgraded to the new release during the preview window ahead of production, which lets you validate the change against real metadata and data. The smart pattern is to treat each release as a checkpoint. When a new release is announced, open Release Updates, sort by the nearest enforcement date, and work the items that apply to you first. Some updates Salesforce can enforce automatically once the date passes, and others may have been scheduled for a specific instance, so checking your Trust status timeline alongside the page keeps the dates accurate for your instance.
What Test Run does and why it matters
Most Release Updates include a Test Run option, sometimes labeled Test Now, that activates the updated behavior in your org so you can observe the effect before committing. The safest place to use it is a sandbox that has been upgraded with the upcoming release, because you are exercising the new behavior against a realistic copy of your configuration. A Test Run lets you click through the affected flows, run your Apex test suite, and confirm integrations still behave under the changed rules. If something breaks, you fix it on your timeline rather than under pressure on the enforcement date. Treat a failed Test Run as a finding, not a blocker. Log what failed, fix the configuration or code, and run it again until it passes cleanly. The reason this step earns its place in a release routine is cost. A problem caught during a Test Run is cheap to fix. The same problem discovered as a production outage after automatic enforcement is expensive in both engineering time and user trust. The Test Run turns a future surprise into a task you scheduled.
Applying, monitoring, and not letting items pile up
After an update passes your testing, you can apply it deliberately rather than waiting for automatic enforcement. Applying early on your own schedule means the change lands when your team is watching, not on a date Salesforce picked. The Release Updates page tracks which items you have addressed and which are still pending, so it doubles as a checklist for the release. The failure mode to avoid is letting items accumulate. If you skip the page for a few releases, you can arrive at an enforcement date with multiple untested changes hitting at once, which is exactly the pile up the page was designed to prevent. A steady cadence beats a scramble. Many teams assign an owner for release readiness who reviews Release Updates every cycle, files the affected items as tasks, and reports status before the deadline. Salesforce also streamlined the email notifications that accompany major releases, so you can pair the in app page with the email reminders to make sure the right people know an enforcement date is approaching. The combination of in product tracking and notifications keeps preparation honest.
Where Release Updates fit in a release readiness practice
Release Updates are one piece of a broader release readiness practice, not the whole thing. New features arrive through release notes and are usually opt in, while Release Updates carry the changes that can break what already works. A mature team treats them differently. Release notes get a scan for opportunity, and Release Updates get a structured test pass because the downside of ignoring them is real. The supporting cast includes sandboxes refreshed for the preview window, a test plan that prioritizes high value and high usage processes, and tools like DevOps Center or change sets to move any fixes you make from sandbox to production. Salesforce Optimizer and Health Check round out the picture by flagging configuration that may be affected by tightening defaults. The practical workflow is simple to state and worth repeating every cycle. Read the updates, test the ones that apply in a preview sandbox, fix what fails, deploy the fixes, then apply or let the platform enforce the change. Done consistently, the enforcement date becomes a non event because the work already happened during the window.
How to work the Release Updates page each release
Release Updates is managed from a single Setup page. The goal of the workflow is to review every update that applies to your org, validate it in a preview sandbox, and address anything that fails before the enforcement date. Do this once per major release.
- Open the Release Updates page
From Setup, enter Release Updates in the Quick Find box and select it. The page lists updates relevant to your org with a status, an impact summary, and an enforcement release for each item.
- Sort by enforcement date
Work the items with the nearest enforcement dates first. Open each card to read the full description and the steps Salesforce recommends so you understand what the change touches.
- Test Run in a preview sandbox
Use the Test Run or Test Now action in a sandbox upgraded with the upcoming release. Click through affected flows, run your Apex tests, and confirm integrations behave under the changed rules.
- Fix what fails, then re-test
Treat a failed Test Run as a finding. Adjust the configuration or code, deploy the fix to the sandbox, and run the test again until it passes cleanly.
- Apply or let it enforce
Once testing passes, apply the update on your own schedule so the change lands while your team is watching, or let the platform enforce it on the published date.
Shows whether an update is ready to test, in progress, or already applied or enforced, so the page works as a release checklist.
The release in which the change becomes mandatory. Plan your testing backward from this date for each item.
Activates the updated behavior so you can observe its effect before committing, ideally in a preview sandbox.
Explains what is changing and why, plus the steps Salesforce recommends to prepare. Read this before deciding the item applies to you.
- Run Test Now in a sandbox upgraded with the upcoming release, not in production, so you are testing the real new behavior against a safe copy.
- Do not skip the page for several releases. Untested updates can stack up and all enforce at once, which is the pile up the page exists to prevent.
- Enforcement dates can be instance specific, so confirm your timeline against your instance Trust status rather than assuming a single global date.
- Release Updates cover behavior changes that can break existing work. They are not the same as opt in new features in the release notes, so review them with more care.
Prefer this walkthrough as its own page? How to Release Updates in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Manage Release UpdatesSalesforce
- View Org Changes in One Location with Release UpdatesSalesforce
Straight from the source - Salesforce's reference material on Release Updates.
- Manage Release UpdatesSalesforce
- Release UpdatesSalesforce
Hands-on resources to go deeper on Release Updates.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does the Release Updates Setup page list for administrators?
Q2. How many releases does Salesforce ship per year, driving the items on the Release Updates page?
Q3. What does the Test Now button on a Release Update let an admin do before enforcement?
Discussion
Loading discussion…