So I understand that in Dynamics 365 for Operations, new security elements (e.g. Roles, Duties, Privileges) can be created in 2 ways: either through Visual Studio, where they belong to a model and a package, and exist as an .xml file. Or, via the UI (ie. the browser) where they exist in the database only. I also understand that a synchronization will push the .xml security elements into the database to live alongside the other UI-created elements.
The Visual Studio-created security elements (the .xml files) can be added to VSTS, for source control. They can also be added to deployable packages to be promoted to other environments. This would be my preferred method of development and promotion, as the elements are safer because of VSTS.
But I don't see any way to get the UI-created security elements under source control, other than having a developer recreate them manually in Visual Studio.
Does any one have some experience with this? It seems like a rather disjointed, difficult-to-manage approach to security development.
I currently have a situation where a functional resource (unbeknownst to me) has been creating some new security roles via the UI, in a DEV/TEST (Build) environment. Obviously these are not currently under any kind of source control, and would be at risk of being destroyed if someone was to restore a copy of a different data set over the top of this environment (as is done periodically during the implementation phase).
Are the UI-created elements actually being saved as .xml files somewhere that I'm not aware of? Or are we stuck with this split approach to security development?
Any feedback or first-hand experience would be appreciated! Thanks!
