You have probably seen that a new SLDS 2 theme was released a few months ago. Read the following article to know how to preview new SLDS 2 theme, and enable it, in your Salesforce instances !
BEFORE MIGRATING TO A NEW THEME
As you already know, this is the way a Salesforce record (a well-known account in this example) is displayed in Salesforce, with the current theme :
a Record detail page, with current theme
Current theme – Record detail page view
a Related lists page, with the same current theme
Current theme – Related list page view
PREVIEW THE NEW THEME FIRST
To preview or/and enable the new SLDS 2 theme, go to Setup > Themes and Branding. You will then ve able to see both :
The active theme in this instance is the classic (and efficient) Lightning Blue
The recent Salesforce Cosmos SLDS 2 theme, on the last line of the tab
Setup – Themes and Branding – Current configuration
It is always a best practice to preview a theme before activating it (as it is for all release update / new feature). It avoids bad surprises. To preview SLDS 2 new theme, select the Cosmos SLDS2 line, click on the down arrow button, at the end of the line, and click on Preview.
Setup – Themes and Branding – Preview new theme first, before activating it
You can now navigate throughout your Salesforce applications, to see how the components and pages render with the new theme. For information, you will get a banner, on the top of your page, to easily quit the theme preview mode (« End preview » link):
Top banner reminder, allowing you to quit the preview modeNew SLDS2 theme – Record detail page view with the new themeNew SLDS 2 theme – Related list page view with the new themeNew SLDS 2 theme – An example of a new record page layout, with the new theme
As always, the View option (from within the down arrow button, on the theme line) allows you to see the branding details / color palette of the theme
View Theme – Just for visualization (or modification for custom ones)
ENABLE A NEW THEME (SLDS 2 still in Beta, though)
If you want to customize a theme for your instance, please create a new one (« New Theme » for SLDS2 theme, « New SLDS 1 Theme » for a standard SLDS1 theme), and customize it. This way it will be easier to come back to the standard theme.
Setup – if you want to customize a theme, please create it first (SLDS 1 or SLDS 2)
A new theme will then be available in the Themes and Branding tab !
Then, once you have made up your mind about the theme to leverage (standard OOTB SLDS 2 Cosmos theme, or new customized one created as presented before), go back to previous screen, select the theme that you want to activate in the Themes and Branding tab, click on the down arrow button, and choose « Activate » to activate the chosen theme.
Setup – Themes and Branding – Activate a theme
Be aware that this theme feature is still in beta, and thus there coud be some side-effects, as reminded by Salesforce.
Information banner explaining the SLDS 2 is still in beta
If you activated the SLDS 2 theme and – due to some issues – you want to go back to former theme, go back to setting, select a standard SLDS 1 theme (like the famous « Lightning Blue » we have already mentioned) and activate this one. The theme will then get back to normal.
One of big announcement of Salesforce TDX 2025 is the possibility to provision a developer edition with all Agentforce related features available in it. We will show how to provision it.
And great precision – compared to former Agentforce / Data Cloud playgrounds with which you may have played for your Trailhead modules so far – this Agentforce-fueled Dev Edition is available as long as your regularly use it (one login every 45 days !).
The QR Code to flash to get your own AI-fueled personal Dev EditionAgentforce Dev Edition home page
For information, other news about Headless / Agentforce API have been shared during this session ; Agentforce is not only used by an human
New features related to Agentforce, centered on enhancing the interaction with the platform
This communication echoes some previous materials shared by Salesforce teams, like the two following ones, available in Youtube, on Salesforce Developers‘ account, published a couple of weeks, before TDX’25 event :
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
You have probably already faced a flow error message telling you that your scheduled flow was handling too many records. How can we avoid this error by limiting the number of retrieved records, as we would do in SOQL / Apex with a LIMIT ?
Flow error message when handling too many records
It now comes to an end with new Spring’25 Flow enhancement allowing you to define a limit number of records retrieved by a Get Records element.
First, an idea was opened 5 years ago to ask for the possibility to add a limit on this Get Record, which is eventually a way to operate a DML operation, as you would have in SOQL with the LIMIT notion.
Here is a screenshot of this idea :
Idea on IdeaExchange at the origin of this feature
Since then, Salesforce’s Spring’25 release update brings now the possibility to specify the number of records to retrieve, in your Get Records elements (from 1 to 20 000 records).
Flow Builder – Get Records details pane – New choice to limit the number of retrieved records
To do so, create a new constant number resources from the resources manager pane in Flow Builder (this way you will define this limit at a variable level) :
How to proceed to leverage this feature – Create a new variable to store the limit number
Thus, you would be able to use this resource in your Get Records element, as described here. You could naturally also define it directly here under, if that is something used only once in the Flow. But, as for now, I would suggest to keep and use the variable.
How to proceed to leverage this feature – Leverage this new variable in your Get Records element
Naturally, some complementary logic (some examples after) may need to be reviewed in your daily scheduled flows, to be sure you do not miss records (to be handled, but whose quantity would be greater than the limit value set) :
Create a scheduled job to launch the flow more frequently
If you have some date-related conditions in your flow, make sure that your flow is able to handle records from the day before (and not only today’s records as you may see in many scheduled flow samples)
In parallel, make sure to have the proper order set up in your Get Records, to handle older records that may have been forgotten from a previous daily execution, accordingly to your requirements. For example, use an ascending (ASC) order to be sure to start by the oldest records.
The Conditional Formatting feature has been progressively deployed in Salesforce instance, as a Christmas gift in advance, after Winter’25 upgrade. The time has now come to discover it, on your Salesforce instance.
To be able to use this feature, you should have migrated your concerned Lightning Page within Dynamic Forms.
In your Lightning Page Builder, click on the field, on which you want to add this visual formatting configuration. In the detail right panel, you will find a new Conditional Formatting section.
Click in the Component, and either edit the existing ruleset, or add a new ruleset by clicking on the « + Create Ruleset« . See below an example for the Priority field of the Case object.
As for now, you can only define the new ruleset name ; the other filled are grayed out and already filled in. It seems that we will soon be able to format fiels with other possibility than an icon (keep an eye to the roadmap)
Once the ruleset is created, we are asked to add every possible rules concerning this field. The pieces of information to provide are both a condition, and an icon with a color to use when the field value matches the chosen condition.
Eventually, the ruleset should include all rules set for this field. It will be displayed this way :
The ruleset configuration is now displayed both on the Lightning Page’s configuration page :
on the record field, with an Artist Palette icon next to the field component, indicating that there is a specific formatting applying :
and in the detail panel, on the field configuration with the ruleset name mentionned
Testing the ruleset, you will see below how the chosen icons are displayed, accordingly to the picklist field values. Here are some examples for the Case’s Priority field :
It is important to mention that the icon only appears on the Lightning Page. The value of the field is not impacted. You will not get this information in a list view or a report for example !
Remark : You will probably begin to remove soon all formulas, which you have probably set up so far (with a concatenation of an emoji and a field value) to simulate such feature
You can also access the Conditional Field formatting information, directly from the concerned object page, in Object Manager, instead of going through every pages.
In our case, when we click on the « Conditional Field Formatting » option in the Case object manager, we see the newly added configuration
When you created a Salesforce Sandbox, the user creating the new sandbox was kept active to be able to login in this new sandbox, but all the other ones were created inactive.
Now, since the last release, you can choose to keep active, all the users of a Public Group, by example an Admin / Tech Lead active group, or for release deployment user, that may be granted access on all sandboxes.
You are required to select a public group. That means you need to configure such Public Group to be able to go beyond this screen. As it is an one-off operation, that is something you can configure up front, and review when needed when resources leave or arrive.
As you can see on the screen, the group is mandatory. Otherwise, it will generate an error asking you to enter a valid group name
If you were used to develop, and never jumped to VS Code installation on your workstation, you can now access Code Builder, with a much more professional user experience than Dev Console.
Follow this step-by-step guide to enable Code Builder, directly in your Salesforce Org.
You will need to enable from within your Production instance, but would be naturally able to work since then in your developer sandboxes. It will require a production license for each developer needing to use Code Builder, but does not need to be a full Salesforce business license.
Setup – Code Builder – Enable Code Builder
A new package version has been available since early May
The package is then available in Setup > Installed Packages
You can then either enable the Code Builder license to the Platform Integration license,
or manually assign the related permission set group to the concerned users
Remark : you would see the following permission sets when going through the related detailed permission sets
To Launch Code Builder, go to App Launcher
Code Builder instance is then loading in the browser, with an URL address looking like: https://nameoftheinstance-name.fra.001.sf.code-builder.platform.salesforce.com/?folder=/home/codebuilder/dx-project
After loading you will see a screen that will ring a bell :
Let’s connect the instance on which you will work (sandboxes) as you would do with your VS Code’s Command Palette
To do so, please follow the following instructions :
Click on Connect an Org button from previous screen. Then, in the displayed popup, select the kind of sandbox to connect to, as you can do, with VS Code’s Command Palette
Enter an alias to easily determine the instance
Once the window is loaded (could take a while), please click on the cloud icon, in order to open the Org Browser.
When you choose Open the Org Browser, all the configured instance metadata is retrieved and displayed in your local project under the root directory.
Then to access detailed configuration, choose the metadata in the left panel, and choose to Retrieve and Open Source
Now you can modify and push your code, from CodeBuilder, to your developer sandbox. As in VS Code, be always aware on the sandbox / instance, which your Code Builder is connected to.
Salesforce has made available, an org analysis feature, called « Scale Center » to all their Unlimited Edition Client. It has been made available on Full Copy sandboxes as well.
The feature is accessible from the setup menu (look for « Scale Center » in setup’s Quick Find box). You still may try to contact your Salesforce AE, to get, or try to activate the solution for your Salesforce instance.
First, get to Scale Center section, select Org Performance, and activate the feature.
Scale Center – Welcome screen to launch the analysis feature
Once activated, Scale Center will run to collect and analyse your data. It will need a couple of hours to gather all measures.
Scale Center – First data collection process
After performance measures collection, the admin system will be able to define either a quick observation range (last 4h / last 12h / last 24h until now) or define more accurately the time frame for data observation.
Scale Center – Simple range definition on last few yearsScale Center – Custom base range between 2 dates
The Admin System will also be able to compare the time frame, with a previous one, by clicking on Compare checkbox, and then define the second timeframe.
Scale Center – Time frames comparison
Here is below a sample of a performance measure chart on a long time frame
Scale Center – Restitution of the overall performance on a time range
The tool allows the Admin user to define a 30-minute long slot, to deep dive on outliers, or anomalous data that may be highlighted in such chart.
Scale Center – Deep dive on a time slot selection
From this 30-minute long selection, the System Admin will be able to generate either :
a dedicated report on a specific axis (Apex, or Database..)
a consolidated report, gathering metrics related to all topics of the list below
Scale Center – Report generation starting from the previous time range definition
Start a new analysis report, see report status,
Scale Center – Report definition
From the Setup menu (Setup > Performance > Scale Center > Performance Analysis) a system admin can access all performances reports generated from within the previous screens. You can consult there the last 100 reports generated within your Salesforce Organization.
However, be aware that the generated reports will expire after 30 days.
Scale Center – Analysis report generation in progress
The Performance Analysis report will take a few minutes to be generated. During this preparation time, when clicking on the report in progress, the report is not yet available.
Scale Center – Analysis report not available because in progress
When ready, the report will be accessible by refreshing the page ; it will be tagged as available, in the Analysis related list, from the previous screen.
Scale Center – Analysis report available for consultation after generation
In Winter’24 preview, there is a new feature that is in beta testing, that allows to consolidate and present an overall vision of all permissions present within a given Permission Set.
To access this summary, you should navigate in Setup, to the given permission set, and click on « View Summary (beta)«
A complete summary of all included permissions, of this Permission Set, is then displayed, without needing to deep dive in the usual permission menu (that you could see in the grey section of the bottom of the previous screenshot).
The top section of the page displays :
A first block with the Permission Set summary information,
Information about all permission set groups, which include the Permission Set
The section below presents :
The System Permissions present within the enabled Permission Set (before you had to go to the System Permission sub menu, and scroll through the whole page with all System Permissions, to see which ones have been enabled),
