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.
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.
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.
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.
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.
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:
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:
Furthermore, we can see that the ‘General’ and ‘Major’ profiles have other common classes, meaning we can divide up further:
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:
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.
Place all Profile metadata files in the \input directory (you can specify another directory for input and output if desired)
Run this command (sample input files provided): dotnet SalesforceProfileRefactor.dll \input \output
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:
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:
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.
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.
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.
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.
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.
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.
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: