Periodic updates pertaining to organization-wide limitations, governor limits, etc. are released by Salesforce to improve the usability, stability and system performance. Because these updates may affect the existing customizations, Salesforce lists them in “Critical Updates” and sends out an alert to the admins to review the updates when they go to set up. Each update can be manually activated or deactivated several times to evaluate its impact on the organization and modify the affected customizations accordingly. If the manual activation or deactivation is not done in a particular time frame, Salesforce auto activates the update permanently. Let me explain this with a few examples –
Example 1: Text Encrypted Formulae Field
Suppose an admin has had a business use case wherein he needs to use a text encrypted formula field. But even though he used an encrypted field, data is visible, which is a security breach in Salesforce. To rectify this issue Salesforce would release critical updates, the same way as we get OS updates on our iPhone or Android devices. Some people might have already used this feature (text encrypted formula field), thinking it to be expected behavior. Now, if Salesforce imposes the updates all of a sudden, it impacts the business of the customer due to the existing customization done by them. Therefore, to avoid such impacts, Salesforce releases critical updates periodically and sends out an alert notification (to confirm) to all the admins asking them if they would manually update or let the system auto-update the fixes.
Example 2: Clickjacking in Visualforce
Example 3: Lightning Locker Service
One more example is the introduction of locker service critical update. Lightning locker service is a security feature in Lightning which protects us from security vulnerabilities and other loopholes which come along with the use of components from different sources and third-party libraries. When Salesforce introduced Lightning, there was no locker service feature. After a few releases, Salesforce released locker service which isolates components that belong to one namespace from the components with a different namespace. But even though Salesforce issued locker service feature now, few users might have already started using Lightning components without locker service. If Salesforce released this critical update immediately, all the communities and components they developed would have been impacted. So, Salesforce released critical updates with a particular time frame and sends out an alert asking developers to implement locker services in their code or else they would be auto-updated.
Example 4: Extension of critical updates time frame
Let’s assume an admin of the company received Locker Service critical update. A company implemented a lot of Lightning components in their org and the time frame given by Salesforce was not sufficient to update all the components. The admin decides to reach out to Salesforce by raising a critical ticket asking Salesforce not to impose the updates in their org as they are still working on updating the code. If several other admins also raise similar tickets to Salesforce, they would extend the time frame of the auto-activation window.
How to manage Critical Updates?
To manage critical updates
This page shows the list of various updates issued for your organization. A summary on why the update is issued for, an activation link to test the update in sandbox or production before Salesforce auto activates it on the scheduled auto-activation date. A review link to view the impact it would have on the customizations with or without the update being executed.
Why does a company need to respond to Critical Updates?
The Critical Updates fine-tune the drawbacks/loopholes in the system. These updates are scheduled to be automatically activated after a period of time. Even though these updates don’t impact every org, but sometimes may have a negative impact on the existing functionalities. Therefore, Salesforce recommends every admin to respond to the critical updates by analyzing the impact of a Critical Update, take proper steps or workarounds and activate the update manually.
New Critical Updates
Enforced Critical Updates
These critical updates were announced in a previous release and are now enforced.
Enabling external org-wide defaults in orgs with communities or portals was a critical update in Spring ’19 and is enforced for the Summer ’19 release. This update enables the External Sharing Model and helps you secure your data. You can set more restrictive levels of access for external users instead of giving internal and external users the same default access.
Postponed Critical Updates
These critical updates were announced in a previous release and the auto-activation date was postponed.
This critical update, released in Spring ’18, was scheduled for auto-activation in Summer ’19 but has been postponed to Winter ’20.
Solunus, a North-American based company, prepares businesses for their next generation customers. Established in 2014, we simplify Salesforce for you to build more meaningful customer relationships. We partner for a win-win arrangement with clear ROI that the client realizes by the end of the engagement. Our 350+ years of industry exposure, project management expertise, and Salesforce experience underpin our position as a problem solver.
About the Author:
Vamsi is a 3X certified Salesforce professional having over 3 years of experience in Salesforce. Having started his career at Solunus, he has worked on multiple projects using Sales Cloud, Service Cloud, Community Cloud and CPQ. When he is not working on the platform, he is seen travelling and has a fondness for automobiles and gadgets.