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
Répondre

You have probably already faced flow error telling you that your scheduled flow was handling too many records…

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 :

Since Salesforce’s Spring’25 release update, you can now specify the number of records to retrieve, in your Get Records elements.

To do so, first, create a constant number resources, from the resources manager pane :

Thus, you would be able to use this resource in your Get Records element, as described here :

Do not forget to mention a sort order if relevant.

Naturally, some logics 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)

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 :

WINTER’25 – Create a sandbox with already active Key Users

Publié le par
Répondre

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

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 :

Code Builder – Setup – Step by Step activation guide

Publié le par
Répondre

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.

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