Indeed, this topic was postponed, and is back again in your release update listing for upcoming Salesforce Winter’25 release. So how do we prepare for this API retirement ?
Accordingly, when this release update is live, external applications, which consumes these old Salesforce REST / SOAP / BULK API versions, will stop working, as these calls will fail (endpoint is not found).
Identify if your Salesforce instance is called through an old API version
Please navigate to Setup > Event Log File Browser to investigate. Then, once you have landed on the tool page, launch an analysis of your API Total Usage, on a daily basis, on a 1-month duration, here for example, from February 1st to February 28th.
This way, it provides a sufficiently broad window to ensure that all usages will be caught in this analysis, and that all calls to versions lower than v30.0 will be detected.
Event log file browser usage – Target API Total Usage on a daily basis
Once the time frame is selected, and you have chosen « API Total Usage » and a « Daily » interval, click Apply.
Event log file browser usage – Study every file on a day to day / file to file approach
For each day, download the file (click the arrow at the end of each line).
Event log file browser usage – download all files of the observed period & open them all in VS Code
Then, open each file, and look for API version below v30.0. In my case, I have handled this search with VS Code application. To find all the v21.0 to v30.0 usages occurrences, I have used the following regular expression : « (30|([012]?[0-9]))[.][0] »
Use VS Code’s Find feature with « Use Regular Expression » option (Ctrl+F then Alt+R) – Make sure to use proper double quotes in the regular expression !Visualization of a file downloaded for all API Usages of a specific day (VS Code used for this part)
Make project teams adapt their calls to Salesforce
Besides, once you have found some occurrences using soon-to-be deprecated API versions, you have all that you need to identify where they come from :
« API_RESOURCE » : the URL resource that is involved in this API usage (« query », « update », « DescribeSObjects », « v29.0/query », « /v29.0/sobjects », « /v27.0/chatter/users/me »...)
« USER_ID » : the user who has called this resource
After you have grouped all these usages (by application type or by user), contact the different project teams to ask them to update their connector or code.
Maybe, have you received this communication from Salesforce after Spring’25 release update, either for your Production instance, or your non-preview sandboxes :
ICU activation failed – Do not worry..! Prepare for Summer’25 next slot
For Salesforce Spring’25 release update, ICU locale format was planned to be activated. I will explain how to prepare your Salesforce org for upcoming ICU format release update for Summer’25 if you have missed Spring’25 activation ?
But indeed, as mentioned in the documentations from Salesforce, you will find under this article, this upgrade from JDK previous format, towards ICU international format, was only possible if all technical (Apex, Visualforce, and Lightning) components of the platform were compliant (above API 45.0 version). If your Salesforce instance contains lower API versions of these components, Salesforce won’t enable ICU locale formats in your org, and indeed you should have received this email.
If ever you are concerned by the unsuccessful upgrade, and you received this email, please do not worry, and read the following article. There will be another ICU format activation slot, linked to next Summer’25 release upgrade (June 2025).
Introduction : What’s behind ICU Format ?
As an introduction, just to know what is behind the ICU letters, in this help article, Salesforce details the impacted locales / users, and the differences between both JDK and ICU formats for these locales :
A very straight-forward Action Plan, within just a few steps !
Assessment of your useR locales : Who will be impacted by ICU Update
From a pragmatic point of view, you need to tackle all technical actions, listed by Salesforce, to make sure the upgrade could pass next time. I suggest that you follow the procedure & query detailed by Salesforce in their exhaustive documentation (see below). You will find below a short version of it based on the actions I have followed on the instances I handle.
First, query your org to see your impacted users, and their locale. For information, Canada (en_CA locale) requires a specific activation to handle separately.
SELECT toLabel(LocaleSidKey) LocaleName, LocaleSidKey, Count(id) UserCount
FROM User where IsActive=true GROUP BY LocaleSidKey
ORDER BY Count(id) desc
You would be then able to visualize the way your date / values informations will be displayed (important, especially if you have some text manipulation of those data types).
Enable the ICU feature on a sandbox first
Go to Setup > Release updates, look for the ICU release update, click Get Started, and enable it. Do it first in a sandbox, and test that it does not generate regression errors in this sandbox ! Then apply on other sandboxes, testing instances and after that in Production.
Identify technical components to update to stick with ICU Release Update
As written above, if your instance contains technical components (Apex classes, apex triggers, Visualforce pages or components, Lightning components, managed packages), Salesforce asks you to upgrade their API version.
Always use as a target the Production version (target v62.0 for example, even when Preview sandboxes are in v.63.0 version) to prevent you from being blocked when deploying your updated components in Production.
To identify them, you may either leverage SOQL query on concerned Salesforce technical objects, or use a dedicated list view on each of these component types in Setup pages.
a « Classes < v45.0 » view, for Apex classes (see the example below)
a « Triggers < v45.0 » view, for Apex triggers
a « VFP < v45.0 » view, for Visualforce pages
a « VFC < v45.0 » view, for Visualforce components
a « LWC < v45.0 » view, for Lightning components (Aura and LWC)
You may also query your instance (on ApexClass, ApexTrigger, ApexPage and ApexComponents objects) with Salesforce Inspector Reloaded, if more convenient for you.
SELECT Id, Name, ApiVersion, IsValid, NamespacePrefix
FROM ApexClass
WHERE ApiVersion < 45
ORDER BY ApiVersion DESC
Upgrade your code to a version compliant with ICU format
As written above, navigate through Setup, select the concerned components (for example « Apex Classes » for Apex classes) setup page, click on the metadata to update, Edit, access the « Salesforce.com API » version line, and update to target version.
Class version in v44.0..just changed in a click to v62.0 (you can also open them in Dev Console if more convenient to do it)
If the component is compliant, the class will be updated within the correct version. Otherwise, you will be warned when saving, that there is an error in it, as you are when you are coding / saving in Dev Console / VS Code.
In this case, some changes would need to be undertaken while updating the code version of your components. For example, in API 59.0 version, the getSalesforceBaseUrl() method has been deprecated. So if your code includes a call to this method, you have 2 options :
update this class to the latest / more recent compliant API version, where the method was available (v58.0 in this case) ; that could go faster for this time, but that is something that will need to be addressed sooner or later..
take advantage of this overall « platform-related action plan », to include some refactoring technical actions / tickets to update the code (here, in this example, replace the method by a call to getOrgDomainUrl() available since v59.0)
Update your packages
Update the unmanaged code to the latest Apex version, as you have done previously
Update your managed packages (through AppExchange updates)
If you use Salesforce related packages (Marketing Engagement / Pardot, Marketing Cloud Connector), Salesforce should enable this kind of features with their automatic release updates. As an admin, you still can update the package if nothing is available.
If you use 3rd-party-vendor’s managed packages (for CTI, for Org assessment, or for any feature improvement scenarios), you would necessarily need to look for package updates on AppExchange, or on the asset homepage / repository. Do not hesitate to contact the editor company if there is no update available.
Deployment in UAT for Non Regression testing, before Production
Deploy these technical elements before activation, in UAT for non-regression tests
Code to be deployed / updated first
Managed packages to be updated after, accordingly to the action plan you have set up for your test sandbox.
Once done and tested, deploy into Production, as soon as the tests on UAT are successful, and you will be ready for next ICU activation slot !
PS : If you have many teams working / deploying on Salesforce, do not forget to let them know about this action plan. They will need to be consistent concerning both coding / deployment / testing actions
Free Salesforce swag is always something that Trailblazers, Salesforce clients, and Salesforce-addict consultants are looking for… but when it comes to free licences, that’s a whole other issue !
In last TDX2023 (TrailblazerDX 2023) on March 7th and 8th, Salesforce announced the addition of 5 FREE Integration user (= API Only) users for their clients (with Salesforce Enterprise and Unlimited editions), to be deployed, in a phased way as of March 14th, with additional licences at a very challenging price.
And, here they come !!
Salesforce, with its last Spring’23 patch 13.1, introduced the Salesforce Integration user license along with a Profile named API Only.
As indicated by its name, this new profile is dedicated to back-office operations / integrations.
5 new licences added for free and available for integration/technical user assignment
Naturally, in past and ongoing Salesforce implementations, Salesforce Architects and Technical Lead still recommend to use dedicated user (with either System Admin or Custom technical-oriented profile) to handle integration use case within Salesforce (still with proper connected app configuration as a best practice).
Each integration type is often covered by a dedicated user (or at least it should be).
That often leads to contexts with up to 3 or 5 dedicated integration users for integrations. Even if is aligned, this way, with administration & security standards, all these users consumes « all included » highly-priced « business » licenses slots.
From an admin point of view, there is no need anymore to create / clone new custom profile (who has cloned it from System Admin profile with out modifying it ? Moreover, who has always handled them directly as Admin ? ). The new API Only profile is here on the shelf.
New Profile – API Only naturally – accessible in Salesforce setup
As it is an « API Only » enabled profile, the users who will be assigned this new profile, will only be dedicated to integration use cases, because users would not be able – as it should always be the case for technical / integration users in order to avoid security-related access issue – to login to Salesforce login page by using the user credentials (that generally never expire, by the way).
The existing and new users – dedicated to integration use case – are now to be transferred / created with this new license and profile. Have fun & free some licenses !
Just be cautious about :
Automatisms / Apex code / bypass triggers… that may leverage profiles names. They should be taken in account concomitantly with the profile assignment switch to the new license/profile.
Check your integration after your license switch (with non-regression testing) on sandbox before impacting the configuration. Obvious comment, but that does not hurt to write it 😉
License and profile are available, as the others, in user creation setup page
For information, to be complete, an known issue has been logged by Salesforce, because some clients, who had already created a custom « API Only » profile with the same security idea, have encountered issues in their code. The issue is currently handled by Salesforce and will be solved in an upcoming patch.
In addition :
A Integration licence will be available in Developer Editions to test the feature
For customers who would need additional licenses, it will be possible to buy additional licenses at a very challenging $10 per user per month price (current public licences price shared by Salesforce).
