There are many different options available to fix or address segregation of duties (SOD) and licensing issues in D365FO, I wanted to show the different options available so you can apply the best option for your particular scenario.
Please note:
- The options provided for possible solutions are not a complete list of every possible way to address the issues
- With the scenarios below, if you are modifying out of the box security layers (roles, duties, or privileges) it is best practice to clone the out of the box security layer and make your changes there instead of modifying the out of the box object.
- None of the information below is audit advise, this is purely educational on the options available to potentially help with SOD or licensing issues
YouTube Link
I recorded a video version of this blog, it is available here: https://youtu.be/Q_OLNxl4RZg
Potential Options for Fixing SOD/Licensing Issues via Security
Because SOD and licensing in D365FO are both based on security assigned to a user, the options for fixing the issue we will look at in this post will be security focused. This does not mean the below are the only ways to address these issues.
The options we will go through are:
- Removing role security from the user
- Modifying role access by removing assigned duties or privileges
- Modifying role access by removing privileges from assigned duties
- Modifying role access by modifying object access from assigned privileges
Identifying Issues with SOD and Licensing
I am going to provide two different ways to identify SOD and licensing issues in D365FO, one will be the tools available natively and one will be using the Fastpath solution which I am a lead developer on. The reason for this is that there are instances where the native reports and functionality do not provide enough detailed information to provide actionable data.
Segregation of Duties – Native D365FO
I’ve documented the D365FO native features/reports surrounding SOD here: https://alexdmeyer.com/2022/05/03/segregation-of-duties-in-d365fo/
The scenario I’ve set up in this case is to assign the SARA user the ability to maintain vendors as well as maintain vendor payments. This creates a risk as a user could potentially create a fictitious vendor and then pay that vendor. Within D365FO I set up a Segregation of Duty rule for the duties ‘Maintain Vendor Master’ and ‘Maintain Vendor Payments’.
After performing the ‘Verify Compliance of User Roles’ process we can see the SARA user is in violation of this SOD rule:
Let’s take the top entry here and look at ways to resolve it, in this case the violation is that the SARA user is assigned the ‘Purchasing Agent’ role along with the ‘Accounts Payable Payments Clerk’ role and those roles give access to the duties we put into conflict. Because D365FO only does SOD at the duty level we are somewhat limited on the actions we can perform to fix this from a security perspective.
We could either:
- Remove either the ‘Purchasing Agent’ or ‘Accounts Payable Payments Clerk’ role from the SARA user (or both roles)
- Remove the ‘Maintain Vendor Master’ duty from the ‘Purchasing Agent’ role
- Remove the ‘Maintain Vendor Payments’ duty from the ‘Accounts Payable Payments Clerk’
With the SOD methodology used by D365FO and the data available in the system, these are really our only options to remediate the issue. Unfortunately these options are fairly ‘heavy handed’ in the sense that performing any of these will probably impact the day to day operation of the SARA user and may not be feasible to perform. So the company would either have to accept the risk and place some sort of mitigating control around it or remove the SOD rule entirely even though this is an entirely valid rule to have (which I have unfortunately seen happen).
Segregation of Duties – Fastpath
Fastpath approaches SOD with a different methodology than D365FO, we always look at SOD at the securable object level within a system. Within D365FO, this means at the menu item, table, data entity, and service operation level. We also have an out of the box SOD ruleset with 115 rules out of the box, this out of the box ruleset includes the segregation of duty rule I had to manually create above within D365FO.
If we look at the Fastpath report below (User Risk Detailed) we are looking at the same scenario we did within D365FO but with much more detail. We are still looking at the SARA user, the SOD risk in this case is called ‘Process Payments and Settlements & Vendor Master Data’ but this is still looking for instances where a user could potentially create a fictitious vendor and then set up a payment to that vendor. In the report below you can see we show the Role -> Duty -> Privilege -> Securable Object hierarchy to show exactly what objects a user has access to that is causing the risk.
With this additional level of detail we now have a number of different options we could do to fix this particular conflict. We could of course perform any of the actions presented within the D365FO scenario above but we can also:
- Remove the privileges from the associated duties (for example remove the ‘Post payment transfer journal’ from the ‘Maintain vendor payments’ duty)
- Remove the securable object accesses from the privilege (for example remove the ‘Post’ menu item action from the ‘Post payment transfer journal’ privilege)
- Lower the securable object access to Read (for example changing the access for the ‘Payment Transfers’ menu item display on the ‘Maintain Vendor Payment Transfer Journal’)
The reason we have these additional options is because we have the additional data at the securable object level.
Licensing – Native D365FO
I’ve documented the native D365FO licensing features/reports here: https://alexdmeyer.com/2021/01/25/current-state-of-d365fo-user-licensing/
The scenario I’ve set up here is that the APRIL user is assigned a custom role I created called ‘FpVendorRole’ this role which requires an Operations level license and we want to try and reduce the license requirements for this user.
If we run the User License Counts report we can see it accurately determine this user requires an Operations license and lists the FpVendorRole as the culprit:
The User License Estimator report shows this user as requiring some sort of base license but cannot determine which (if the user shows up on this report they require a base license but since none of the bubbles are filled there is no indication on which is required):
With the information provided the only options we have for addressing this issue are to:
- Remove the role from the user
- Manually review a report like the ‘View Permissions’ report in the Security Configuration form to see which objects within the FpVendorRole are causing the role to require this license level and then remove them
Licensing – Fastpath
In Fastpath, there are a number of different reports at both an overview and detailed level that will give you the ability to not only see what licenses are required but also why they are required.
The first step in this case is to look at the User License report and being able to identify this as a scenario we could potential resolve in the first place. Because the report also gives you the number of entry points at each license level you can see that in this case there are only 3 entry point accesses at the Operations level which are requiring this user to be assigned this license. Without having this viewpoint of the data, I would not be able to easily tell that this is a scenario I could easily fix using the out of the box functionality.
To get the detailed information required to fix the issue, our User License Details report shows the user -> role -> duty -> privilege -> securable object -> license requirement. This additional level of detail shows you exactly why a particular user is required to have that license as well as gives you the necessary information to address the issue.
Since all of the object access is at a Delete access type, we can also look to see if the objects themselves have a different license requirement if we were to lower the access to a Read access type. If we look at our Security Objects report we can see the ‘View User License’ parameter for each of these objects is ‘Team Member’. Therefore, if we were to lower the access type from Delete -> Read we could lower the license requirement as well:
So with this additional information what options do we have for addressing this issue:
- Remove the ‘Maintain Vendor Master’ duty from the FpVendor Role
- Remove the privileges listed from the ‘Maintain Vendor Master’ duty
- Remove the objects listed from the respective privileges
- Lower the access for the objects listed from ‘Delete’ to ‘Read’
Conclusion
I hope that this post helps with understanding the options you have as an end user to addressing your SOD and licensing issues within D365FO and the capabilities of native D365FO as well as other solutions.