I’ve written in the past about Dynamics 365 for Finance & Operations Security and how it differs from previous versions of Dynamics AX, now it’s time to look at how to set up security within the application. I will show how to do this from the user interface (in this post) and from the AOT (in a follow up post) while giving pro’s and con’s of each.

Setting up security in the user interface

To set up security from the user interface, log into D365FO and navigate to System Administration -> Security Configuration. After navigating here you will be presented with a similar screen to the one below, I’ve broken the screen down into different sections based on their function.

• Green box – Allows you to switch between roles, duties, and privileges
• Blue box – Has a number of different options for performing against the currently selected role/duty/privilege
  • Undo/Redo – undo/redo customizations applied to this security layer
  • Create new – create a new security layer
  • Show all levels – by default D365FO will only show 4 levels of fly-outs in the navigation, this option will force it to show a horizontal scroll bar to fit all fly-out levels
  • Delete – remove the current security layer
  • Duplicate – create a clone of the currently selected security layer, allows you to give it a new name
  • Copy – copies the current security
  • View Permissions – shows an entire hierarchy of security for the currently selected security layer
  • Audit Trail – shows the history of all changes made to an object either from user interface or through AOT
• Red box – listing of all current objects in selected security layer
• Pink box – shows details about currently selected security layer object including Description and AOT name
• Purple box – shows all of objects that are either assigned to this security layer or that this security layer is assigned to, the plus icon (+) designates that there are objects already there. So in this case this role has duties, privileges, and tables assigned to it but does not have any sub roles or parent roles.
• Light blue – all changes made in the user interface must be ‘published’ before they go live, this object lists all of the changes that are not currently published yet

If I wanted to add a duty to this particular role I would then click on the Duties button within the References area (purple box above) and the menu bar would change slightly:

• Add references – allows you to assign a currently available security layer object from a lower layer and assign it to the current layer (ex: duty -> role, privilege -> role, privilege -> duty)
• Create new and add reference – allows you to create a new security layer and assign it to the current layer (ex: create new duty and assign it to the currently selected role)

If I wanted to remove a duty from this particular role, I would select a particular duty currently assigned to the role and the menu bar would again change slightly:

• Remove reference(s) – allows you to remove a single or multiple references that are currently assigned to a security layer

To change object permissions you will need to navigate to the Privileges area, find the privilege you would like to modify, find the object assigned to the privilege you would like to modify and select it. You will be presented with a fly-out similar to the one below. From here you can set each access type (Read, Create, Update, Delete) to a specific access level (Unset, Grant, Deny).

What’s the deal with Unpublished Objects?

When a user makes a change to security in the user interface, this change does not go live immediately. Instead it goes to the Unpublished Objects area within Security Configuration. To make security changes actually become active, you will need to go to this area once your changes are done and either select ‘Publish all’ to publish all changes made or select individual changes and select ‘Publish selection’ to only publish certain security changes.

Where do security changes done in the user interface get stored/saved?

In previous versions of AX, when you made a change to security within the application that change was propagated back to the AOT and went live immediately, this is no longer the case within D365FO. This is because of the change to the overall architecture of the application as a whole (the design time and run-time are no longer within the same environment) changes to security made within the user interface are not pushed into the AOT. Instead these changes are put within what Microsoft calls the ‘security delta’ and are stored as data within the database instead of metadata code within the AOT. So when the security framework looks to see what a particular role, duty, or privilege has access to it first looks in the AOT, then looks at the security delta to see if any customizations need to be applied. It then takes a combination of these two (with the security delta taking precedence) and uses that to determine what a security element has access to.

How do you export/import/move/source control security changes made in the user interface?

Because security changes made in the user interface are not stored as metadata in the AOT, the next question is ‘How do we manage these changes?’ Luckily Microsoft allows for that by allowing users to export/import all of their security customizations done in the user interface to an XML file. This file can then be taken to another environment to imported or can be used in source control so you always have a record of any security changes made in the user interface.

This functionality can be found under the ‘Data’ menu option in the menu bar.

Conclusion

I hope this overview helped with getting acquainted with setting up security from the user interface with D365FO. A follow up post will show how this all can be done from the AOT.