Setting Up Security in Dynamics 365 for Finance and Operations – Part I – From the User Interface

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.

2 Comments

Liese-Marie
on February 20, 2019 at 8:37 am

If I wanted to cancel an unpublished security change, how would I do that? I can see the item in the unpublished objects, but the Undo/Redo buttons are not enabled.

Once a change to a role, duty, or privilege is made in the user interface a record is written to the SecurityUnpublishedObjects and SecurityCustomizedDiskObject tables. There is an Undo button in the user interface which undoes the change but the records in these tables are not removed but they are reverted back to their original state. Which means it still shows up as an unpublished object but there is no change between the old and new security. To remove this you can either publish the ‘changes’ which will have no effect as there isn’t a change in security or remove the affected records in both of these tables manually.