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
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.
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.
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.
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 :
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
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
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),
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.
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…).
In the meantime, 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.
First, 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 – retrieved with SFDX-Hardis extension
I wanted to highlight a special usage I identified about a very well-known (and used) data visualization application : Microsoft Power BI.
In its reports, Microsoft Power BI connection to Salesforce uses default v29.0 version, when the version is not explicitly configured in the report source. That means that Power BI will use this default « soon to be deprecated » version, if you do not specify it.
A PowerBI configuration file, without mention of Salesforce API Apex version
Then, 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) :
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 that you are testing the reports with, are deployed in order to connect with the production instance. Thus, always be sure that your updates are based on the API version of the production instance.
To read more about
Last Salesforce update about v21.0 to v30.0 versions retirement :
