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
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.
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…).
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) :
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
Last Salesforce update about v21.0 to v30.0 versions retirement :
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 valuesNew 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)
Free Salesforce swag is always something that Trailblazers, Salesforce clients, and Salesforce-addict consultants are looking for… but when it comes to free licences, that’s a whole other issue !
In last TDX2023 (TrailblazerDX 2023) on March 7th and 8th, Salesforce announced the addition of 5 FREE Integration user (= API Only) users for their clients (with Salesforce Enterprise and Unlimited editions), to be deployed, in a phased way as of March 14th, with additional licences at a very challenging price.
And, here they come !!
Salesforce, with its last Spring’23 patch 13.1, introduced the Salesforce Integration user license along with a Profile named API Only.
As indicated by its name, this new profile is dedicated to back-office operations / integrations.
5 new licences added for free and available for integration/technical user assignment
Naturally, in past and ongoing Salesforce implementations, Salesforce Architects and Technical Lead still recommend to use dedicated user (with either System Admin or Custom technical-oriented profile) to handle integration use case within Salesforce (still with proper connected app configuration as a best practice).
Each integration type is often covered by a dedicated user (or at least it should be).
That often leads to contexts with up to 3 or 5 dedicated integration users for integrations. Even if is aligned, this way, with administration & security standards, all these users consumes « all included » highly-priced « business » licenses slots.
From an admin point of view, there is no need anymore to create / clone new custom profile (who has cloned it from System Admin profile with out modifying it ? Moreover, who has always handled them directly as Admin ? ). The new API Only profile is here on the shelf.
New Profile – API Only naturally – accessible in Salesforce setup
As it is an « API Only » enabled profile, the users who will be assigned this new profile, will only be dedicated to integration use cases, because users would not be able – as it should always be the case for technical / integration users in order to avoid security-related access issue – to login to Salesforce login page by using the user credentials (that generally never expire, by the way).
The existing and new users – dedicated to integration use case – are now to be transferred / created with this new license and profile. Have fun & free some licenses !
Just be cautious about :
Automatisms / Apex code / bypass triggers… that may leverage profiles names. They should be taken in account concomitantly with the profile assignment switch to the new license/profile.
Check your integration after your license switch (with non-regression testing) on sandbox before impacting the configuration. Obvious comment, but that does not hurt to write it 😉
License and profile are available, as the others, in user creation setup page
For information, to be complete, an known issue has been logged by Salesforce, because some clients, who had already created a custom « API Only » profile with the same security idea, have encountered issues in their code. The issue is currently handled by Salesforce and will be solved in an upcoming patch.
In addition :
A Integration licence will be available in Developer Editions to test the feature
For customers who would need additional licenses, it will be possible to buy additional licenses at a very challenging $10 per user per month price (current public licences price shared by Salesforce).
When deploying profiles to Salesforce, if you ever encounter « You can’t edit tab settings for QuickText, as it’s not a valid tab. », that probably comes from a configuration discrepancy between your Salesforce source and target instances.
« Quick Text »-related error, when deploying profile (here with Gearset solution)
This setting is already enabled in « Lightning version » setup page.
« Quick Text » activation setting in your well-known setup page (User Interface > Quick Text Settings)
As Salesforce help mentions, only Classic instances, with chat enabled, have this setting automatically enabled. Otherwise, you will need to activate it manually, as done below.
So do not forget to switch to Classic, and to activate it too.
« Quick Text » activation setting different from Lightning’s one
Once both settings are enabled, you can keep on deploying your Salesforce project ! Our QuickText issue will disappear as it appeared.
