The definition and implementation of security profiles is one of the most crucial steps in a D365 F&O implementation. Correct security profiles are key for allowing user to maximise the value of the system within their business area as well as setting some boundaries as to what data and forms can be accessed through the system.

Security Basics in D365 F&O

1. Security privilege
   This is where the access level is specified for the different access points in the system. These can be menu items, data entities, specific controls in form or even table permissions.
2. Security Duty
   A security duty is a collection of privileges usually organised around a specific functionality in the system.
3. Security Role
   A collection of both duties and privileges. This is the actual element which is assigned to users. A security role will also determine what license type a user required so, it is very important that user only have access to only the areas which they need to access throughout their business area.

Security in F&O can either be directly defined in the Application Object Tree (AOT) as well as directly in the system using the “Security configuration” form. Both functionalities save the definition of the security elements in the database which allows for this configuration to be exported and imported.

Migrating Security Configuration

D365 F&O has a couple of ways in which a user can export and import the security profile definition. These will be described in detail in this post. It is important to note that when modifying the security profiles (especially through the system) it is the best practice not to directly modify the standard security roles, duties and privilege definitions. This will allow you to always have a fallback when tyring to investigate any issues which require you to compare your custom profiles with the ones which are the defined in the OOTB system.

Migrating through Data management (DMF)

Exporting through DMF is relatively easy. There are a few entities which can be used to identify the customisations done to the security elements in an environment. In order to do this, an export data project must be created which will also generate a data package. The data entities that need to be included within this project are as follows:

1. Security privilege metadata customizations entity
2. Security duty metadata customizations entity
3. Security role metadata customizations entity
4. Security user role association

It is important the previous sequence is also kept. This will allow the system to import data in the correct sequence when the resulting data package is imported in the target system.

After exporting a data project will be generated. The data project will have a file for each entity which is exported but it will also have the XML definition of each customisation which is done to the security elements. These XML files can be found in the Resources folder in the export package and will allow the user to import the correct configuration per privilege, duty, and role.

The next step in this process would be to import the security configuration in the target environment. An import project needs to be created in this case, with the file type as Package. This will allow the user to import the security configuration from the previously exported package. When the project is loaded, the correct entities will be defined in the project.

Migrating through Security configuration

The next approach to exporting and importing configuration is to do this through the security configuration form which can be found at System administration -> Security -> Security configuration. To export a security element (role, duty, privilege) navigate to the Data tab in the action pane and press on Export.

This functionality will export the current selected elements in the of security elements. The result of this process will be an XML file containing the definition of the security element. This is similar to the content in the Resources folder in the previous approach.

In order to import a security element, navigate to the same form and tab but, in this case, select import.

When importing through this way, it is important to remember to publish the changes done to security otherwise these will not have any effect on the users.

Throughout this post we’ve been able to identify some approaches in which security configuration can be migrated from one environment to another, both of which can be done from functional and technical people alike.