As you might know, security-related topics are one of my favorites. It is not only about the technical stuff and how to configure the roles. It is also related to e.g. segregation of duties to prevent possible fraud. It is always fun to work together with a customer to get the best possible setup which is manageable for the application support department. One of the tasks is moving new security configurations between environments.
In this post I will tell you how to do this, but also a neat trick on how to rename newly created security objects as the Security configuration form does not support this.
Type of security changes
It is possible to make changes related to security in several ways:
- Development in Visual Studio
- Configuration on runtime
- Combination of the two above
There is a slight difference in Dynamics 365 compared to Dynamics AX 2012 for managing security. In AX 2012, all security changes ended as security objects in the Application Object Tree (AOT). So, using several code deployment options, the changes were applied on e.g. the production environment. Development changes in Dynamics 365 need to be treated similarly. Using a deployable package, you can move the objects to a live system.
New in Dynamics 365 is the configuration on runtime. Changes are kept in the database and when publishing the security changes, objects are maintained on runtime only. There is no link with the development environment. This does not mean that you would change the security configuration on your production environment directly. Changes need to be tested first. As there might be a lot of changes that needs several test cycles and reconfigurations, the logging will be dirty and not very readable if there are too many changes. So, like other developments, it is recommended to start in a dev/test environment. The production environment will only get a cumulative, approved security configuration which is logged only once.
Move the security changes
When you have changes in security configuration that need to be moved to another environment, you can simply use the action buttons on the security configuration form. I will show the steps in detail.
To start with, I created a new security role: The Sales Assistant. This person is able to view customer details and is allowed to maintain sales orders. When this role is tested and working as expected, we want to move it to another environment. To do so: Click Data > Export. The security changes will be exported in XML format which can be downloaded. You can store the configuration file within your own library.
Now you can open another environment where you can import the security configuration. Open the Security configuration form. Then click Data > Import. You will be prompted to specify a file name. The file you just saved would be the one that needs to be provided. Then click on OK.
The file will be processed and the changes will be visible on the form. On the Unpublished objects tab page, you will find all modifications.
In this case, I used standard duties. If there were more changes, you could see more objects and object types. Note that exporting the security configurations will export all configurations; not only the one you are focusing on. To be able to have the imported configuration active, you have to Publish all or select one or more records and Publish selected.
Renaming security objects
When you have made a mistake in typing a friendly name for a new security role, duty, or privilege, there is an option to create a new object and use the correct name or spelling. However, if you are live, the references are based on internal IDs. There is no option within the security configuration form to change the name once the object is created.
There is one simple trick that I tried once and this is working like a charm.
As described above, you can export the security settings and save the file on your computer. Then use an (XML) editor to open the file. When you don’t have such software, you can even use Notepad.
Note that the name of the role is a GUID ID. This ID is the primary key for letting the import know if a new role should be created or an existing one should be modified. All newly configured security objects do have such GUID where objects created in Visual Studio would have a readable object name.
When you have saved the file, you can import the file and publish the changes to correct the name(s).
I do hope you liked this post and will add value for you in your daily work as a professional. If you have related questions or feedback, don’t hesitate to use the Comment feature below.
That’s all for now. Till next time!
Image by Gerd Altmann from Pixabay 
Image by Pexels from Pixabay 
Image by Thomas Breher from Pixabay 
Image by Gerd Altmann on Pixabay 
Is it possible to undo changes? If I made several changes in the test environment, but only 1 should be published in the live environment (at this time), i would like to “undo” the other changes, so they disappear from the Unpublished list in my live environment (preventing someone to accidentally “publish all”).
Hi Mona,
I thought the Synchronize button would do this, but recently we had changes in an environment which were not published. So, I’m invetigating the behavior now of the repair and sunchronize now. Probably one of my next blogs will be related to this topic.
You can also try to edit the security configuration xml file and remove the objects which should not be published.
I experience an error when importen, due to my use of sub roles.
The error seems to be, that when creating RoleA (that contains Role B) it cannot find Role B since it is not created yet.
I think using sub roles is the best way, so I am very disapointed with this limitation, what are you guys doing?
BR Kenneth
Hi Kenneth,
I’m hardly using sub roles. So, I haven’t seen this issue yet, but can imagine you would have an issue. You can use selections and first publish role B. Then you can publish role A. Hope this will be a solution for you.
kind regards,
André
which method do you consider as a “best practice”, and why/in what situations?
deploying security changes through deployed packages, or making the changes in runtime and using Export/Import?
Hi Zvika,
I can share some words as food for thought. The best option would depend on e.g.
Customization <> Configuration
Visual Studio <> Security configuration in UI
Developer <> (technical) consultant
Deployment software package (downtime) <> File movement (agile)
ALM story/version control <> Manual storing configuration export
Application metadata <> Database storage
It would depend on preferences, skill sets, available development licenses, ALM requirements, and agility. This can be different for every organization. At least, I think, when performing customizations, you should make the related security part of the software. The best practice checks part of the build process will then check if every menu item is covered with a privilege, a privilege is linked to a duty, and the duty is linked to a role.
Hi André,
A very insightful post.
When a security configuration contains custom roles created through the UI, can you confirm that via the xml export/import operation from one environment to another, is the SECURITYROLEIDENTIFIER (guid) maintained?
Also would the import reset the user role assignments per organization in the target environment?
Hi Hayssam,
When moving the security roles with the standard data entitities or export and import option on the Security configuration form, the identifier (GUID) will be maintained. In case there is another role with the same name, but another GUID, you can’t import it as a validation prevents you from doing this.
In case you import details from an existing role, it wil not reset the existing user role assignments.