Move all user and security settings with data entities
In this post, I will explain how you can move all user and security settings using data entities with Microsoft Dynamics 365 Finance and Operations. There are several ways to move the users and the security settings. I will focus this blog on the data management features.
Options to move user and security settings
When we talk about moving user and security settings, we can define the different types of settings:
- Users
- Security role assignments
- Security role, duty and privilege configurations
There are data entities for the users and role assignments. These are developed to be used with data management and are also enabled as public, so you can use the Excel add-in or other OData endpoints like Microsoft Power Automate.
The changes on security roles can be moved using deployable packages in case they were changed using the development environment. If you did customize the security using the Security configuration form, you have two options: Use the export and import from the security configuration form or data management.
What to use would be based on your own preferences. There is no real best practice as all options are created by Microsoft and thus supported. One advantage of using data management would be the option to have all user and security settings moved at once at the same moment.
Scenario
As a scenario for this blog, I started to have two equal environments which represent a test and a production environment. A new role with some standard and new duties and privileges is created for the Internal sales employee. The highlighted security artifacts have been customized using the Security configuration form.
Also a new user is setup which got this role assigned. Next to the security role assignment, there are organizations assigned to limit the access to two legal entities only.
Move user and security settings
When making the changes as mentioned above, we now want to synchronize all security from the test environment to the production. For that purpose, you can create a data management export project like shown below.
While adding the data entities, you can expect some information and warning messages. You can ignore them initially. Only when the data related to a specific security object is too large, the data can be truncated. This would cause an error or inconsistencies when you import the data package. I haven’t seen this happening yet in my projects.
A brief explanation of the used entities:
User information | Data entity containing the users with user options. |
Security privilege metadata customization entity | Data entity to export and import privileges which are added or changed using the configuration option. |
Security duty metadata customization entity | Data entity to export and import duties which are added or changed using the configuration option. |
Security role metadata customization entity | Data entity to export and import security roles which are added or changed using the configuration option. |
Security user role association | Data entity for handling the security role assignments to users. |
SystemSecurityUserRoleOrganizationEntity | Data entity for handling the organization assignments to security role assignments. |
Security segregation of duties rule | Data entity for the segregation of duties rules. |
Security segregation of duties conflict | Data entity for the segregation of duties conflicts. This entity has unresolved, but also reviewed conflicts. |
You may want to use these entities all together or work with single or some entities at a time. At least, you need to ensure the data you move will be consistent. It had e.g. no use to import Security user role associations when the corresponding security role or user is not in the target application.
Using the level and sequence, you can set dependencies to ensure data will be processed in a certain order and that some data will not be imported before certain entities are fully executed. You can read more about the sequencing on Microsoft Docs. To be honest, I did not set the correct order for the segregation of duties entities. I realized it when typing this blog.
When the export project is ready, you can Export the data directly or using the batch framework. When you have larger number of users, customizations and role assignments, executing in the background is recommended.
When the export is completed, you can download the package. When you enabled the option on the export project to directly create the package, the application will directly create a data package file on the Dynamics 365 storage for download. When you have not used that setting, it will ask you to create the package file before you can download it. You can save the package file which can be used to import in another environment. You save it on your preferred location and can rename the zip file.
In your other environment, you can create a new data management import project and load the data package file.
You can start the import directly or via the batch framework. The same recommendation applies like mentioned above for the export. If you have larger number of records, it would be better to run the import in the background.
After the execution succeeded, you can see the result and compare it with the expectations. The total number of records per entity are the same. In this case the Created column shows the new records created for the new user, security role with details and role assignments.
The security configurations which were not in the target environment initially are not only imported; they have been directly published and the security role is ready to be used without additional user interaction.
There is more…
There are two more data entities related to the security available out of the box. I haven’t used them in the example above.
Active Directory Security groups | You can use this entity when you want to export or import the Azure Active Directory Security Groups. The related feature needs to be activated via a license configuration first. You can learn more how to use Azure Active Directory Groups for maintaining security in my blog post on this topic. |
System security user role organization | The name of this entity is misleading. It is not interacting with the organization setup. Actually, this entity is almost the same as the data entity Security user role association. This entity is having an additional column for the license type related to the security role. The entity which can export and import organization assignment on security role assignments is mentioned above and has the name SystemSecurityUserRoleOrganizationEntity. |
When you are using the automatic role assignment rule for managing security access for users, you will find out that there is today no data entity available to export and import these configurations. To be able to have one in a future release, I created a new suggestion on the Dynamics 365 Application Ideas website. You can vote for this idea to get it prioritized by Microsoft.
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!
Hello, I have duplicated your method to import security configuration, but when I start the import, I have the message : Security customization data cannot be loaded. Please contact your system administrator. There is a specific manipulation to do ? thank you for your feedback
Hi Jerome,
Can you tell in detail how you exported the configuration and how you start the import? Did you only use data management framework? Are the source and target environments having the same application models?
Getting the same error for a custom role that was created from scratch. Cannot move custom roles from an environment to another.
Hi Daniele,
I would like to understand more about the contents of your role and if you perhaps already had a role with the same name in the target environment. Can you provide more information? You can also create a question on the Dynamics Community.
Hi André, I was not using the “Download package” function. Now is working. Thanks for the useful content!
Thanks for your reply. I overlooked the option that you might not used the package. When exporting the security information, the contents of a role, duty, and privilege are stored in an XML file referenced from the export file. So, indeed just e.g. an Excel file is not sufficient for moving security. Definitely, the package is to be used.
Hi, I’ve found the above blog very useful in extracting security data from D365 into BYOD so we can use it to tie up with Azure SQL Database users and database roles to protect EXECUTE on stored procedures. Especially so since the tables do not appear to be available to create customer entities from. However, the SystemSecurityUserRoleOrganizationEntity appears to be used in your example, then you point out that it actually has the Licence Type and not the Organisation assigned, then you point to that same entity as the source of organisation assignments. I’m a little confused. Where can I get hold of single organisation grants on user / role assignments – the equivalent of SecurityUserRoleCondition in AX2012?
OK, scrub that, I’ve just noticed that this particular entity does not have the spaces between “words”, so didn’t pop up in the list once I started typing in the entity name box. May be worth pointing out the difference between “System security user…” and “SystemSecurityUser…” for the uneducated like me 🙂
Thanks for reading and commenting on this blog post. Yeah, the naming of the data entities is not fully consistent. I can imagine your confusion here.
Hello, thank you for the very useful post.
I would like to move all users and security settings from a test to a production environment.
Firstly, I want to have a simple test to move a few users and their security settings only.
Is there a way of doing this in Data Management Framework?
Should I use filtering option when exporting entities related to user and security settings?
Hi Michael,
You can indeed set ranges with the Data Management Framework. There is another alternative. If you export the data as a package using Excel as file type, you would be able to edit the Excel sheets before you import them in another environment.
In your table you list the entity named “System security user role organization” and the following sentence “This entity is having an additional column for the license type related to the security role.”
Do you know what the numbers in this column means. In our system I can find 0, 4, 6 and 7.
Hi Søren,
There is a system enum called UserLicenseType having the next options:
Some values belong to AX2012 where the last options are related to Dynamics 365.
Hi Andre, thank you for such a wonderful guide to exporting security roles in F&O. This is immensely helpful. I was able to download the package, rename and store it away just by following the steps shared above.
In fact, I created a custom role yesterday and was wondering if you could also share how to filter custom security role records as a follow-up to this post. Thanks in advance!
Hi Austin,
Thanks for your feedback to my post. What exactly do you mean by filter custom security role records? The entities I talked about in this post are only exporting the customized roles, duties, and privileges. It is not exporting untouched standard objects.
Hi Andre,
Thanks for the blog.
I wanted to understand these 2 things:
1. When I open the customizations role/duty/privilege file, I see GUIDs under Identifier Column in most places instead of the names assigned while creating the custom objects.
2. There’s a column XmlObjectFileName which I believe might be holding the details about the customized security object. But will it work across tenants? Or it will only work for environments which are under a single project on LCS.
Thank you
Hi Mohammad,
Thanks for your questions. Here are my thoughts:
1) In case you create custom security objects via Security configuration, it is creating an ID representing an “AOT object name” using a GUID. Security objects which are in the standard application and created via Visual Studio do have a readable AOT object name as defined by the developer.
2) The XmlObjectFileName indeed refers to a file with all contents of a security object. When you create a data package, the files are in the resources folder in the zipped file. This can work across environments and across tenants but only in case the source and target environment do have the same security objects in the AOT. If e.g. the export has security details about an ISV solution which is not in the target environment, the import will fail.