You may have recently received an email from Salesforce with the subject Your Salesforce Release Update Enforcement Was Unsuccessful with regard to the ICU Locale updates. It's likely not the first time you've received such a message between attempted enforcement in sandboxes and production environments. It's prompted lots of questions, so we wanted to answer what we know about this update and what impact it has on your org, based on Salesforce's latest updated guidance.

The headline: lots of–if not most–Salesforce orgs received this notice due to Apex or Visualforce code in managed or unmanaged packages. In some cases, this includes packages like NPSP from Salesforce, as well as prominent packages from vendors like Classy (now GoFundMe Pro). It can also include widely-used open-source packages like those from UnofficialSF. Receiving the notice isn't a reason to panic though–let's look at what the change means, and what it means if it failed to activate in your org.

What's changing?

Before API 47 (Winter '20), Salesforce defaulted to returning all localizable strings like dates, times, and currencies in Oracle's Java Development Kit (JDK) format. This controls things like the order of months and days in dates, appearance of currency symbols, and display of positive/negative values.

In the Winter '20 release, Salesforce changed that format to the International Unicode Consortium (ICU) format. You may best know ICU as the standards body the defines emoji, but they also set standards that most of the tech industry adopted for text encodings. Salesforce decided to adopt the ICU format to improve compatibility across external products.

So, this release update aimed to ensure that all code running on the Salesforce platform returned its localizable strings like dates in ICU format for greater compatibility. But...

Why did I get this email?

There's a fair amount of code that was written in API versions too old to understand ICU formats. Because the Salesforce platform only used JDK formats, developers probably didn't make an effort to support any other format, which could cause problems if you swap a JDK formatted string for an ICU formatted one. API 45 is a kind of shorthand for "code old enough to potentially have problems if the date, time or currency string formats change." So, if your org has code that old that's why you got the email–Salesforce did not enable the update to avoid breaking existing code.

Can't I update the code myself?

For custom code that isn't contained in managed packages, the answer is yes. You can update and test code in a sandbox to ensure that nothing breaks when it's changed to a new API version. In some cases, the change will be as simple as updating the version in Developer Console or VS Code, running test classes, and pushing the code to your production org. As part of this process, you may need to change or update logic in your code if it shows issues with a new date or numeric format introduced by ICU.

For managed packages, though, you'll have to wait for the vendor to perform the updates, because only the package developer can make changes to it.

Should I panic?

Does anyone ever say "yes, panic now?"

No, no need to panic. You're not alone–lots of orgs are in the same state. There are a few things to keep in mind.

First, just because there's old code in your org, it doesn't mean it's affected. If the code in your org isn't working with dates, times, numbers or currency values, there may be no impact even though it's "unsupported." Vendors may be choosing to update such code more gradually to avoid causing other compatibility issues.

Second, if you primarily have users in the US, the list of changes between JDK and ICU format is very minor–there are a total of four of them. In this table, the JDK format is on the left, and the ICU format is on the right.

For US users, the primary impact is likely to be potentially inconsistent display of values in Visualforce pages. If you have non-US users though, it would be a good idea to review the full list of changes.

Will it be like this forever?

Definitely not. Salesforce has said that they will likely aim for enforcement of the update in the Summer '26 release next year. In the intervening months, more vendors will update their code. Salesforce itself updated a bunch of its older code, including all of the code in Volunteers for Salesforce (V4S) to version 62 on June 15, 2025. So next summer, the story likely will be different. Salesforce has committed to continuing to support JDK formats while they continue updating more products, and to continue "analyzing the impact of orgs remaining on JDK."

What should I do now?

While you can't update the version of code in a managed package, you can check in with the vendor to see if newer versions are available. Major vendors like S-Docs have updated to avoid older code. You can ensure that you are running the latest version of packages from major vendors and reach out to any vendors that don't have compatible updates to inquire as to their roadmap.

If you use unmanaged packages like open source components from UnofficialSF, you should also ensure that you've installed the latest versions, which is good advice in general.

This is also a chance to do some spring cleaning–if you have packages installed that aren't being used, uninstalling them can ensure there won't be ongoing issues, either due to ICU formats, bugs, or security issues.

Some older packages also may no longer be available or supported. A very popular example is Field Trip, which still has a lot of API 30 code in it, but was removed from the AppExchange in early 2025. It may be time to assess if you need a replacement for a beloved older package.

Have specific questions?

Please feel free to reach out! We'll be happy to answer any specific questions about your org! PROserve customers can submit a request via the Request Log, or sign up for a free Office Hours session.