In a couple of previous posts (Setting Up Security in D365FO – User Interface and Setting Up Security in D365FO – AOT) I described how the actual security elements are stored differently in D365FO depending on where creation/modification is done at. If a security element is created/modified in the AOT, it is stored as code in the context of whatever project you are currently in. If, on the other hand, you are in the user interface security gets stored as data in the database in what Microsoft calls the ‘security delta’. When the security framework looks to determine what a role has access to, it first goes to the AOT and then looks in the security delta to see if any changes have been made to the security role. If they have, the user interface changes override any changes made at the AOT level. This presents an issue if you want to take changes made in the user interface and convert them to code to be used in the AOT. So I decided to see if it was possible to take the XML that is generated from the security customizations exported from the user interface and process that to generate the XML file(s) needed to set this security up as code in the AOT.
Evaluating AOT Security Files vs User Interface Security File
Comparing the AOT security files and the output from the user interface security export, I noticed that the files shared the same structure. The only real difference was that the user interface security file contained a listing of all changes made, so all roles, duties, and privilege changes existed in one file. I also noticed that once a change was made to a role, duty, or privilege in the user interface the entire security object was copied into the security delta table not just the changes. This was important because if I could parse the file and pull out each individual security layer object I could create the XML files as if they were created in the AOT.
So we can take an input file that looks like this:
And break it out into the individual roles, duties, and privileges that have been customized in the user interface in the format needed for the AOT.
Output folder structure:
Output files broken out by security layer types:
You could then take these XMLs to a Visual Studio security project, add them to the project as security elements, and create a deployable package that could be used to deploy to other environments. This process could help eliminate some of the confusion on what is best practice surrounding security version control as you would now be able to have all changes go through your code promotion process regardless of if the change was made in the AOT or user interface.
I’ve made this project open source and available on my GitHub page. Feel free to use it, make improvements, offer feature requests etc.
Some future improvements would be to handle custom roles, duties, and privileges better (allow ability to rename them).
Very interested to hear feedback on this project!