Security Audit Trail Feature in D365FO

Alex MeyerFinance & Operations2 months ago34 Views

Photo designed by FreePik

Dynamics 365 for Finance and Operations has native functionality to track changes to security that are performed via configuration. Let’s take an overview look at the feature and see what it can do, what the gaps are, and what we can potentially do to improve it.

Overview

I’ve written briefly about this functionality in the past when I wrote about making changes to security via the Security Configuration form in the user interface, but I never really did a deeper dive into it.

This functionality tracks changes made to security layers done using the Security Configuration form in the user interface. Let’s take a look at how this feature works.

If you navigate to System Administration -> Security Configuration and select a role, duty, or privilege you will see an option in the menu named ‘Audit Trail’.

If you click on that you will see all versions of that security layer that have existed. You can then select two versions of the security layer and the ‘Compare Permissions’ button will be enabled:

This will then compare the security layers permissions down to the object level between these different versions. The process for this comparison is as follows:

D365FO will select the earlier of the selected versions of this security and designate it as the ‘Left’ version, and will designate the more recent version as the ‘Right’.
Each object access will then be compared between the ‘Left’ and ‘Right’ versions of this security layer.
The ‘Change Type’ column will then show if this value is ‘Equal’ or ‘Unique’ to one side of the comparison. If the object access existed via the same assignment path in both versions (role -> subrole -> duty -> privilege -> object access), then the system will designate it as ‘Equal’. If however the object access is different or if the assignment path has changed it will label it as ‘Unique’ and the ‘Comparison Side’ column will show if this entry is unique to the ‘Left’ or ‘Right’ versions of the security layer.
- If it unique to the ‘Left’ version it means this assignment existed in the previous version but does not exist in the ‘Right’ version which means the access was removed between these versions.
- If it unique to the ‘Right’ version it means this assignment did not exist in the ‘Left’ version but does exist in the ‘Right’ version which means the access was granted between these versions.

The final type of change that is shown is if the object access exists in both the ‘Left’ and ‘Right’ versions but the assignment path has been changed. An example of this is below where Microsoft marked one of the privileges in the assignment path as ‘[Obsolete]’ and created a new privilege which still granted access to the same object at the same level. In this case the ‘Change Type’ will be listed as ‘Different’:

Gaps

One glaring gap in this functionality is that it does not capture changes made to security via code. For example, if I create a security layer via code, and then update that security layer it is not recorded as being updated.

As an example, I will create a new security role named ‘FpAotTest’ and assign the ‘Inquire into Vendor Master’ duty:

Once I build and sync the solution I can see this role correctly displaying in the user interface:

But if look at the Audit Trail for the role, it is blank:

Now if I go and update the role and change the duty assigned to the ‘Maintain Vendor Master’:

And build and sync again, the role is correctly showing the new duty being assigned:

But the Audit Trail for the role is still blank:

This is also true if I extend (ex: create a customization) a current security layer that exists in code.

For example, if I extend the ‘Accountant’ role and add the ‘View Accountants Entity’ privilege:

When I build and sync the solution, the privilege is correctly showing for the role:

But the Audit Trail for the role does not show any updates being performed relating to this change (the code push was done on Jan 11th 2025):

The bottom line is that this feature will only capture changes made to security layers via configuration, any changes made via code will have to be tracked and compared using your source control system.

How Can We Improve the Current Reporting of the Security Audit Trail Functionality?

One piece of feedback I’ve gotten previously is that ‘it would be great if I could just see an overview of the role/duty/privilege association changes and any direct permission changes between these security layer versions’.

Now this information could be determined by the native security comparison information provided but you would have to comb through the existing object level reporting and manually figure out which security layers were added or removed from a particular security layer version.

By analyzing how the current security comparison code was working, I was able to create my own customization which provides this overview information. Now when I navigate to the ‘Audit Trail’ page of a security layer there is a new menu option named ‘Fastpath Security Comparison’ which will analyze the different versions of the security layer selected and report on any roles, duties, or privileges that were added / removed as well as any direct permission changes that were made.

The Fastpath comparison code will then aggregate the comparisons being done at the object level and show the security layers being added and removed as well as the directly assigned permissions that are changing: