Archives par mot-clé : Tips

SALESFORCE #TIPS – Activate new SLDS 2 theme (Cosmos)

Publié le par
Répondre

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 mode
New SLDS2 theme – Record detail page view with the new theme
New SLDS 2 theme – Related list page view with the new theme
New 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.

Have fun with this new theme !

To read more on the subject

SUMMER’25 – Prepare your Salesforce Org for API v21-30 retirement

Publié le par
Répondre

You probably remember working on this Salesforce « API retirement » topic 2 years ago..! (see the post written for Summer’23 release update back then : https://forcewalk.com/salesforce-summer23-api-v21-30-retirement-summer25-integration-problem-with-microsoft-power-bi/)

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. For each day, download the file (click the arrow at the end of each line).

Event log file browser usage – Study every file on a day to day / file to file approach

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] »

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.

To read more on the subject

Salesforce Platform API Versions 21.0 through 30.0 Retirement : https://help.salesforce.com/s/articleView?id=000389618&type=1


See the post written for Summer’23 release update back then : https://forcewalk.com/salesforce-summer23-api-v21-30-retirement-summer25-integration-problem-with-microsoft-power-bi/

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

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 :

SPRING’25 – Add a limit on Salesforce Flow’s GetRecord elements

Publié le par
1

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.

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 :

SALESFORCE #TIPS – Gender on CustomObjectTranslation metadata

Publié le par
Répondre

When deploying Salesforce-related metadata, configured on a French Org, have you already met this strange error : « Error parsing file: ‘ ‘ is not a valid value for the enum ‘Gender' » ?

Metadata Gender on Custom Object translation – Error message when deploying

In fact all langages, with gender for their nouns, are possibly concerned.

That means that you could face this issue, if you are deploying metadata, between unrelated instances, from an organisation whose langage is gender-oriented, towards an organization whose langage is not.

CustomObjectTranslation – Detail on Gender tag

As a workaround, please go to the metadata repository, which contains your instance codebase.

Metadata Gender on Custom Object translation – Edit the raw file in code repository

In this case, to solve this issue, I have edited the CustomObjectTranslation raw file, from within the code repository, removed the following gender line, and then committed the modified file in the same branch.

<gender> <!-- Feminine --></gender>

Then, within Gearset – but it would be the same with GitHub Actions – please refresh your metadata comparaison to update the file content from your selection, and validate again for deployment. This time, it should be ok, and you should not cope with this error anymore.

To read more on the subject :

SALESFORCE #TIPS – How to manage the deployment error displaying flow’s regionContainerType is required

Publié le par
Répondre

If you have ever met this kind of deployment error

Error SOM_990_Manual_Shipment FOLI_to_Ship_Section1 (Screen Component) - Because the "FOLI_to_Ship_Section1" screen field on the "FOLI_to_Ship" screen is a section, the regionContainerType is required.
Missing regionContainerType – deployment failing due to missing field’s regionContainerType description

That comes from missing information from within deployed flows.

When you see this error, that means that a regionContainerType tag (added in Salesforce flow metadata description in a previous release : v55.0) from a flow’s field metadata component is missing.

To avoid these deployment errors, you shall edit your flow within your code repository, to add, after each RegionContainer definition line, the following tag :

<regionContainerType>SectionWithoutHeader</regionContainerType>

Here is the result of the text edition, in the flow-related raw file, seen, modified and then committed, directly from within GitHub repository

Missing regionContainerType – location of the information to add within the flow metadata

After changing the flow content, the deployment is then validated by Salesforce

Missing regionContainerType – successful deployment after the change

SALESFORCE #TIPS – Share a list view to several users

Publié le par
Répondre

To whom may wonder how to share a same list view to a certain group of users, you should leverage Public Groups.

When creating a list view in Salesforce, you can create it :

  • for your own
  • for all users (you cannot be too selective on your filters, on a wide-open list view)
  • for a set of users from within roles / roles and subordinates

However, when you do want to share a list with a limited number of users, from the same role for example, you could feel that you should need to create a subrole just for it, or open it up to all users because you think you cannot do any other way.

Share a List View – No possibility to share to a group, if no Group had been created first

To be able to target a list of specific users, you could leverage Public Groups

To do so, navigate to Setup > Public Groups > New, create a public group with a relevant name, that would be easy to understand for users who would need to share their list views.

Share a List View – Creation of a Public Group

Once done, you will see that you are now able to share list views with Groups ; this option is now available among the list sharing options :

Share a List View – Sharing to a Public Group is possible when at least a Public Group exists

Here, we share the new list view, with the newly created Public Group :

Share a List View – Example when sharing to a group

To read more on the subject :

URL Hack to reset Salesforce user security token

Publié le par
Répondre

This is not a very new topic, but that is something that I need to explain a few times a year, because I am frequently asked this question by consultants.

When trying to reset a User Security Token, consultants or administrator are navigating through the user settings to discover that the Reset My Security Token is not present anymore in the personal section of Settings menu, on the left side of the page.

Reset Security Token – Click Settings to access the personal settings page to access the Reset Token menu

In My Personal Information menu, in the settings panel, you can see that there is no option to reset the security token, in this instance (example, on the screenshot on the right, where the menu option is missing).

That can be the case when an IP range has been defined for your profile / user.

Reset Security Token – No Reset option

However, if you need to get a Token value, in this case, please consider the following URL hack :

  • Go to the URL navigation bar
  • Append to your Salesforce domain, the following text : 
_ui/system/security/ResetApiTokenEdit
  • And click enter, once done.

A new page (in an old-fashioned Classic look) then appears, unlocking the reset option. From this page, you will now be able to reset the security token of this user, by pressing the Reset Security Token button.

Reset Security Token – Option unlocked within Classic page

To read more on the subject :