A couple of months ago, I found a workaround link to be able to keep on creating cases to Salesforce support (https://help.salesforce.com), the good old way, with no Agentforce in the loop, knowing that I was able to correctly describe it.
https://help.salesforce.com/s/case-submission
By clicking this link, you land on a page that allows you to manually create your case :
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 !
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 :
To preview or/and enable the new SLDS 2 theme, go to Setup > Themes and Branding. You will then ve able to see both :
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.
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):
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
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.
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.
Be aware that this theme feature is still in beta, and thus there coud be some side-effects, as reminded by Salesforce.
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
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 :
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 :
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)
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 :
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 :
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 ?
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 :
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).
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) :
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.
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) :
To read more on the subject :
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 !
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 :
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 :
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 :
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 :
Enjoy you fast data imports with BULK API
To read more on the subject :
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
To read more on the subject :
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' » ?
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.
As a workaround, please go to the metadata repository, which contains your instance codebase.
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 :