Category: SFDX

Salesforce Spring ’21 – Developer Highlights

Salesforce Spring ’21 – Developer Highlights

Salesforce Spring ’21 is nearly upon us, and these are my highlights for Developers from them. Obviously there is a lot more in the notes, so always encourage you to read through fully yourself.


  1. Track Changes between your local Project and a Sandbox

This hasn’t really been a big issue for me since I can rely on Git for determining changes in my metadata, however there may be scenarios where you want to make a lot of configuration changes and this will help you identify and track them better.

2. Create Scratch Orgs with More Features

Great to have more feature control. I just checked and it seems Person Account feature  (that I was looking for) has actually already been available for a while now!

3. SOQL – Select predefined groups of Fields ( SELECT * ) 

I’m not really sure about this one. The lazy SQL developer uses SELECT * and will usually cause issues down the track. Being able to use this in SOQL with SELECT FIELDS(ALL) is convenient, but I’m concerned that developers will just use that by default rather than consider which fields they truly need. This may or may not have performance implications, however it could easily have security implications where some PII data hasn’t been secured. On the other hand, if you need to select all the fields anyway then this will make for cleaner code.

4. Lightning – DOM API changes

Do you have automated tests for your org? (Selenium, Tosca, etc) Salesforce has been changing the way the HTML code is named, so you will probably want to check for breakages in your test suites ASAP.

5. Lightning – Customize lightning-map control

You now have greater control over the behavior of the map control such as disabling panning, buttons, etc, and can define your own map marker icons as well. This isn’t a huge leap, but great to see that Salesforce is still improving this control. There will always going to have the issue that it won’t be allowed to compete with MapAnything, but I find it a valuable control for limited scenarios.

6. Lightning UI components to be deprecated

This was announced a year ago for Spring ‘20, but now the time is almost upon us! As of May 1st 2021 all UI namespace components will no longer be updated or supported.

7. Salesforce Functions (beta)

This has been a long time coming. Formally known as EverGreen (I think, it was hard to keep track) there has always been some rather mixed messaging from Salesforce around this. Still, an interesting new beta feature that could provide you with alternatives to Apex, although not clear if additional licensing is required.

8. Apex Job Transaction Finalizer (beta)

Strange beta in that you can use this in Production from Spring ’21. Use a finalizer at the end of your Apex to handle or rerun failed jobs. I’ll need to spend some time on a POC to understand this one fully.

Creating a Salesforce Permission Set subset from multiple Profiles

This tool is for reducing the size of your Profiles by extracting common elements and placing in a common Permission Set.

Complex Salesforce orgs often have large Profiles, and Users can only have one Profile. This means that when you create a new App or implement a Release Update (for example), then your Admins will need to go through and ensure all Profiles are updated the same way. You will then also have to test each Profile fully.

I created a simple command line utility to identify the most common elements in a set of Salesforce Profiles and generate a common subset Permission Set as well as the newly reduced Profiles.

Salesforce provides Permission Sets and Permission Set Groups that allow you to define a set of Permissions not tied to any Profile. This means for example that if you have 100 class accesses that are needed by multiple Profiles, you could define one Permission Set and assign to everyone who has those Profiles.

In a really simple example, I cloned three new Profiles from the standard ‘Minimum Access – Salesforce’ Profile. (In a real world example this hierarchy would be better defined as Roles). Each has Profile level access to different Apex Classes in our Org:

Initial Profile state

We can see that all these Profiles have access to the X-Wing and Y-Wing classes, so we can add those to a Permission Set:

Reduced Profiles with common Permission Set

Furthermore, we can see that the ‘General’ and ‘Major’ profiles have other common classes, meaning we can divide up further:

Reduced Profiles with two common Permission Sets

Now, the Rebel Alliance has just acquired a new B-Wing vehicle for everyone. To grant access the Admin can now just add this to the main Permission Set, instead of to each Profile:

Adding a new permission element that everyone has access to

For such a simple example it is easy for an Admin to set this up by hand, however what if you have 15 profiles that are thousands of configuration lines long?

The tool generates a Permission Set, however if your common files are still large then I would suggest looking at creating a Permission Set Group and splitting the generated Permission Sets up inside it instead.


This post will only cover the generation of Profile and Permission Set metadata files. The process for pulling and pushing Profile metadata from an org really depends on how well your devops is set up. SFDX tools can pull and deploy Profiles, but not consistently without some issues.

Warning and Disclaimer

Always use this tool in sandboxes and never directly in Production! Try and design an improved Permission Set and Profile combination in a sandbox, and then test that extensively. You need to have personal confidence that the new Permission Set is going to work for your users.

If you do progress to Production, then also do have a roll back strategy to the old Profiles.

Finally, please ensure that you have all the training and knowledge required to pass the ‘Sharing & Visibility Designer’ Certification. You really need to understand how Profiles and Permission Sets work, and all potential impacts to your org. Unit Tests, manual testing and automated testing are rarely comprehensive enough to catch every scenario.


  1. Ensure Microsoft .Net 5.0 is installed on your system (Windows, Mac or Linux)
  2. Place all Profile metadata files in the \input directory (you can specify another directory for input and output if desired)
  3. Run this command (sample input files provided): dotnet SalesforceProfileRefactor.dll \input \output

MacOS Example:

Run the tool from the command line

You will see a new folder generated under ‘Output’ with the current date and time stamp. Inside is the common Permission Set as well as the newly reduced Profiles:

How the tool looks

Open the generated Report.csv in Excel (or similar), and you will see that it has moved 2 Apex Class access elements and 5 user Permission elements into the common Permission Set:

The output report in MS Excel

Changing the code:

The tool has been developed in Microsoft .Net 5.0 and should run on Windows, MacOS and Linux. You can change the code in community (free) versions of Microsoft Visual Studio 2019 for either Mac or Windows.


  1. I chose to do this in C# .Net because I already knew how to manipulate XML with it. Additionally Visual Studio is great at generating the XML schema wrapper class.
  2. At this early stage I doubt there are many people who need this utility. Even I am hoping to use it very rarely. Java would have been a more natural choice for the Salesforce community, but would have taken me longer.
  3. Code Optimization – I traded accuracy and reliability over code speed. I have a recent i7 running at 2.8 Ghz and the whole operation takes less than 7 seconds to process 600,000 Profile configuration lines, therefore I am not too concerned about it.
  4. GUI – I have some thoughts about extending this with a user interface to help visualize the process better, perhaps by comparing specific types of elements and attributes between files rather than all.
  5. Naming – Ensure that the name of the files is correct for either Sfdx or older metadata deployments. I might include this as a command line option in future.

Installing Visual Studio Code and Salesforce SFDX tools without being System Administrator

Installing Visual Studio Code and Salesforce SFDX tools without being System Administrator

I have a new shiny, high specification Windows 10 Laptop from my company. Naturally it is completely locked down from a security configuration.

I’m really fine with this. Developers should always work in least privilege and my company data should always be secured. Sure, it is easier to make progress with your Administrator override buttons, but the pain is just going to come back when you actually need to deploy something.

Microsoft gets this. Visual Studio code installs into my User Level profile without requiring any Admin privileges at all.

However, Salesforce doesn’t seem to get this. As far as I can tell there is no guidance around how to setup your development environment when using a locked down system.

However, you can install with least privilege, but takes a few manual steps which should take you no more than 10 minutes:

  1. Install Microsoft Visual Studio Code
  2. Install Salesforce Extensions for VS Code
  3. Setup Java JDK
  4. Setup NodeJS (with SFDX)
  5. Create a Windows Batch file on your desktop (or wherever):
    • Create VSCodeLocal.bat with a text editor such as Notepad (be careful – notepad will probably put a hidden “.txt” as the suffix)
    • Extend the PATH variable with the Java Bin and SFDX folders, and launch VSCode. See image below.
  6. Double click on VSCodeLocal.bat
    • I recommend running this from the command line first to ensure that no errors are experienced
    • Always run from this batch file. Directly running from the Visual Studio Code desktop/menu icon won’t work.

So at this point you should have a (mostly) working SFDX development environment on your locked down Windows 10. Do let me know in the comments if any steps require elaboration.


  1. Try installing normally first. Your PC may not be as restricted as mine.
  2. Most SFDX commands work, such as ‘SFDX: Create Project’, SFDX: Authorize an Org’, ‘SFDX: Create Lightening Web Component’ and ‘SFDX: Deploy This Source to Org’. I haven’t tested everything.
  3. Installing the SFDX local development server doesn’t work for me because my company policy doesn’t allow scripts to be run. Your mileage may vary.
  4. 100% credit to for the NodeJS/SFDX setup
  5. This process will probably generally work for a restricted MacOS as well. Ensure that you set up launching from the command line in VS Code: Shell Command: Install ‘code’
  6. Versions of all these tools will change all the time. The JDK 11 will probably be fine for years to come, but everything else should be latest as possible.
  7. As far as I can tell, this configuration is likely not supported by Salesforce.