Archives par mot-clé : admin

SPRING’25 / SUMMER’25 – Handle ICU format activation, linked to Salesforce Release Update

Publié le par
Répondre

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.

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 ?

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

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 feature on a sandbox first, and then in production

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

    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

    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

    To read more on the subject :

    SALESFORCE #TIPS – How to know how a package was installed (for which users)

    Publié le par
    Répondre

    When you update a package, except if the former Salesforce consultant / administrator wrote a documentation, there is no specific indication telling you how a package was installed (either in setup’s « Installed Packages » page, or in the package installation/update screen).

    So how to choose how you should grant access to this application / package ?

    First, have a look to this article to see the differences between the suggested options :

    Concerning your instance, open your Salesforce Inspector Reloaded extension (or your preferred solution to query your Salesforce instance). You can directly leverage the query below, on your target instance, to get details on Package Installation Requests records that were made on it (do not forget to check the tooling API checkbox) :

    SELECT SubscriberPackageVersionKey, PackageInstallSource, SecurityType, ProfileMappings, ApexCompileType, NameConflictResolution, CreatedDate, UpgradeType
    FROM PackageInstallRequest
    ORDER BY CreatedDate DESC

    Now, if we want to link this data with the installed package, please navigate through Setup > Apps > Packaging > Installed Packages. Then click on the concerned package.

    On the installed package details page, we can see when this package had been installed.

    It seems quite logical that the package installation is linked to this Package Installation Request record, in our case highlighted in yellow (take into consideration your timezone versus the display in GMT time).

    Now, take a look at the SecurityType field ; this field can take the following values :

    • None : Installed only for System Administrators.
    • Full : Installed for all Users.
    • Custom : Installed for Custom profiles (specified during the package installation).

    This way, when updating your packages, you will be able to step into the footprints of the first installation. Enjoy your updates !

    To read more on the subject :

    SALESFORCE #TIPS – Flow – System.CalloutException with uncommitted work pending ?

    Publié le par
    Répondre

    I built, some time ago, a very simple scheduled flow that only called an invocable method, calling itself an external virtualization system, to retrieve accounts from it, and to copy them back in Salesforce.

    When I ran it, in debug mode (Debug > Run), the flow was failing with a strange « Callout exception » due to pending in-progress work ! (cf picture below) 

    CallOut – Exception message

    But when I call (in anonymous action) directly the method called by the action, it works fine !

    What happens is that there were some DML operations in progress, when the scheduled flow was fired, meaning that some accounts records were not in a stable saved state.

    In this case, you can naturally try to reorganize your code and flows to make sure there will be no element interfering with your DML. But, in case of a refactoring complexity, or short timing, if you ever face this case, to commit the in-progress transactions, you could use :

    • a Screen element (on a screen flow)
    • or a Pause element (on a scheduled flow) : reaching a Pause element ends the current transaction. When the flow resumes after the pause, the Get Records does not face anymore the « pending uncommitted work » exception.

    Eventually, since then, you also now have the possibility to catch errors in flows with error-sensitive Fault Paths. To do so, select the DML-related element, and create the Fault Path from it. You can delete the Fault Path from the same place.

    For information, in a screen flow, you could also have a look and decide to leverage a dedicated custom CommitTransaction element (from UnofficialSF : https://unofficialsf.com/use-the-committransaction-action-to-get-more-from-your-flow-limits/)

    To read more on the subject :

    WINTER’25 – Salesforce API version selector in Workbench – Update of the API version selector

    Publié le par
    Répondre

    The API version selector in Workbench UI had been blocked on API v58.0 since end of 2023 (the API v59.0, matching the Winter’24 release update, and following, were not considered).

    Workbench UI has been updated on mid December 2024, to fit the gap of the versions of all release updates that have occurred since then.

    You can now choose up to v62.0 API version, when using this tool.

    Thanks to the Workbench team for the update !

    WINTER’25 – Post Upgrade – Add Conditional Formatting to fields on Dynamic Forms

    Publié le par
    Répondre

    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

    We can even edit or delete the ruleset from here.

    To read more on the subject :

    SALESFORCE #TIPS – Insert null in a number field with Data Loader (especially in BULK API mode)

    Publié le par
    Répondre

    When you import data in Salesforce, you can naturally force the insertion of null values in Data Loader, when your data require it (fields filled in on certain records, but left empty for others).

    In this case, when you leverage the REST API, in Data Loader, you can check the option to be able to insert null values :

    But, when inserting data with BULK API, you do not have the possibility to force the null values, as you can see in the screenshots below :

    • when clicking the Bulk API option…
    DataLoader settings – « Use Bulk API » option enabled
    • …then immediately the « Insert null values » option is grayed out, and you cannot check it anymore
    DataLoader settings – the « insert null values » is grayed out, when « Use Bulk API » is checked

    To be able to insert data, in Bulk mode, with fields filled in with null values, you have to edit your CSV file, and replace the null values or empty values by the #N/A text, as you can see in the example below :

    DataLoader settings – CSV file with #N/A value to insert null values in BUL.K API mode

    Enjoy you fast data imports with BULK API

    To read more on the subject :

    SALESFORCE #TIPS – Check where a Salesforce self-signed certificate is used

    Publié le par
    Répondre

    When you receive an email form Salesforce telling you a certificate is about to expire, you can see that the communication mentions the concerned instance either in the email subject (Sandbox is mentioned) and in the email body.

    Here are the actions asked by Salesforce to take care of it (copied from Salesforce kind reminder) :

    1. In Setup, on the Certificate and Key Management page, download the expiring certificate. Save it in case you require access to its key in the future.
    2. Generate a new self-signed or CA-signed certificate.
    3. Update connections to external sites or other services with your new certificate.
    4. When your new certificate is tested and in use, delete the old certificate.

    About the certification backup, do not hesitate to create a directory in your company’s SharePoint, just to avoid to lose track of them. You should normally never use these backups, but you never know 🙂

    First, you have to create a brand new self-signed certificate. To do so, please go to go to Setup > Certificate and Key Management > Create Self-Signed Certificate

    You need then to update all connected apps or SSO settings, that were using the ‘soon to be expired’ self-signed certificate, to make them use the newly created one.

    Once done, go to Setup > Certificate and Key Management to navigate towards the ‘soon to be expired’ self-signed certificate, to delete it… or at least try to do so 😉

    Just get your cursor above the Delete button, which is grayed out, and you will know where your certificate is still used. As you can see in the screenshot below, the system mentions in the contextual information, the place where the certificate is still used.

    Here, we may see that we forgot to reconfigure a SSO Setting using this « soon to be expired » certificate.

    In this case navigate to your Single Sign-On settings, in your instance setup, edit your SSO configuration, check the Request Signing Certificate, and update it to the most recent certificate.

    The certificate can now be deleted (the button is not grayed anymore) :

    I would suggest not to delete your certificate right after this operation, but to wait for a week, or at least a couple of business days, to be sure there has been no impact, before deleting it eventually.

    Do not forget to

    • test your SSO login before ending your task !
    • monitor the Identity Provider Event Log (in the setup) to validate that the certificate update has not generated any issue.

    To read more on the subject :

    Winter’24 – Permission Set Summary (Beta)

    Publié le par
    Répondre

    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),
    • The Object permissions
    • The Field permissions

    Salesforce Summer’23 – API v21-30 retirement (Summer’25!) – Integration problem with Microsoft Power BI

    Publié le par
    Répondre

    For Summer’23 release upgrade, Salesforce have originally announced that they will stop supporting API (Soap, REST, Bulk) version from version 21.0 to 30.0.

    Salesforce Platform API Versions 21.0 through 30.0 Retirement

    Release Update announced for Summer’23

    For information, as you can see in recent Summer’23 related communications, these versions will be retired but will continue to run technically until Salesforce Summer’25 release !

    That extra-time gives every Salesforce teams 2 years to update all API usages to newest API versions, and concomitantly ensure in the meantime that the « oldest » API are not used anymore by applications or tools connected to Salesforce (to push data to Salesforce, or get data from Salesforce), in your clients IT landscapes (ETL/ESB, data visualization tools, Salesforce custom API requests from client websites or mobile applications…).

    https://developer.salesforce.com/blogs/2023/05/an-important-update-to-our-legacy-api-retirement-plan

    To prepare for the API retirement, for our clients, we may organize technical discovery sessions with application owner (of all the applications connected to Salesforce) to discover which API version is used by these applications / these usages… but you will need to investigate technically as well through all the applications connected to Salesforce.

    To get all these usages, you may use a VS Code extension like SFDX-Hardis (and especially Detect Legacy API use function)

    Extract of Apex version legacy usages – retrieves with Hardis SFDX extension

    I wanted to highlight a special usage I identified about a very well-known (and used) data visualization application : Microsoft Power BI.

    Microsoft Power BI connection to Salesforce uses default v29.0 version, when the vesion is not explicitly configured in the report source.

    A PowerBI configuration file, without mention of Salesforce API Apex version

    To be able to make PowerBI use the desired Salesforce APEX API version, Data or Business consultants have to mention the API version to use, directly in the connexion configuration (Salesforce Login URL could be replaced by the domain name URL of the concerned Salesforce instance) : 

    Source = Salesforce.Data("https://login.salesforce.com/", [ApiVersion=57.0])

    Just be cautious about :

    • Always work with the version of your production environment

    In Salesforce release preview periods, you may have preview sandboxes on version N+1, although your production and non-preview sandboxes are in version N. It would generate errors if a configured API connection, based on the sandboxes you are testing the reports with, are deployed in order to connect with the production instance. Always leverage on the API version of the production instance.

    To read more about 

    Salesforce Spring’23 – Data model – new Gender Data Fields

    Publié le par
    Répondre

    In Spring’23 release upgrade, Salesforce deployed new gender fields : Gender Identity & Pronouns.

    This data model upgrade concerns Lead, Contact, and Person Account objects :

    • API names on Lead & Contacts : GenderIdentity & Pronouns
    • API names on Person Account : PersonGenderIdentity & PersonPronouns
    Change modal to accompany clients to adoption of Gender Data

    By the past, Salesforce had already implemented these fields in their Non-Profit Success Pack (NPSP). With Spring’23 release, it is now integrated in Salesforce core platform, beyond mere client referential, feeding all the clouds, especially marketing products.

    New GenderIdentity standard field on Contact standard object – Picklist values
    New Pronouns standard field on Contact standard object – Picklist values

    Equality is a strong core value at Salesforce, one among the 5 core values on which Salesforce relies (Trust , Customer Success, Innovation, Equality, and the more recent Sustainability) and develop all its business.

    As Salesforce mentions they wish to provide to their employees an ecosystem where they can feel themselves the way they are, it was natural for them to deploy in their products, for their customers, the same kind of attention, they provide to their employees.

    Just be cautious about :

    • The fields are not yet available on unrefreshed Non-Preview Sandbox.

    The fields had been deployed/delivered by Salesforce on production environments (with Spring’23 release upgrade, early February) and on preview sandboxes (early January). However, be aware that non-preview sandboxes had not been upgraded with these fields. So you may experiment some CI/CD issues or deployment errors, if you use automatic integration/deployment processes and tools, because they will identify a data model discrepancy, and they will not be able to deploy these standard fields. A sandbox refresh is still possible to update your non-preview sandboxes to match Spring’23 delivered data model, but it is still a laborious operation that needs to be planned and well organized among all teams / users / stakeholders.

    • These fields may not appear on your extractions. They may even generate errors !

    As the fields came in with API v57.0, you will need to use this last v57.0 API version to access these fields. Otherwise Salesforce API will not let you access them.

    Error when querying new gender fields in current « not v57.0 compliant » Salesforce Inspector / API

    For example, Salesforce Inspector is still in version 1.14 aligned with Winter’23 release (v56.0) while a GitHub Pull Request has been created in Salesforce Inspector’s GitHub repository to ask the author to make the extension compliant with latest Salesforce API.

    To read more about (publications et guides written by Salesforce)