I have written in the past about how to use the Security Diagnostics for Task Recordings feature within D365FO to help determine the securable objects consumed during a recorded business process or task. But I found while diving deeper into using the tool that there are some gaps that you need to be aware of.

The Gaps

1) The access required for the objects is not shown

If we look at the example output of the security diagnostics for task recordings tool, we can see that the menu item name, label, and type are shown and you also have the ability to select a user from the drop down and see if they have access to each object in the recording. But unfortunately the access type required for the object is left out. This means that there is no way to identify if the access to the object should be granting access at a Read, Update, Create, or Delete level.

2) It will only show menu item displays, not menu item outputs or menu item actions

If we analyze a task recording where we performed a business process that contains either a menu item output or action and we analyze this using the diagnostic tool we can see that this object is missed. For example, I have created two task recordings in one I executed the User License Report (which utilizes a menu item output) and in the other I executed the ‘Check for Duplicates’ process in the Global Address Book (which utilizes a menu item action). When I uploaded these to the security diagnostics for task recordings, neither showed these objects being consumed during the process.

3) Object accesses that are tied to a form control are not shown

If we analyze a task recording where we performed a business process that consumed an object that was tied to a form control we can see that this object is missed. For example, I recorded myself completing a sales order but when we analyze the recording we can see that this action is missed. Normally these items are either menu item actions or outputs so even if the security diagnostic tool could capture this scenario it would still not show up as the tool does not look for menu item outputs or menu item actions.

4) There are certain situations where security is done either in X++ code or is stored in the database, neither of these are picked up either

There are unique situations within D365FO where security for a task is not present in a task recording at all, instead it is handled either directly in X++ code or is actually stored in the database. For example, the menu item needed to delete/remove/deactivate an address is dependent on how you are accessing the addresses form. For example, if you want to be able to to delete an address from the Vendors page (VendTableListPage menu item display) then you would have to assign access to the DirPartyPostalAddressDeactivateVend menu item action. But if you wanted to delete an address from the Customers page (CustTableListPage menu item display), you would instead have to assign the DirPartyPostalAddressDeactivateCust menu item action.

Below you can see how this is set up for addresses on the vendor’s form via the VendTableFormHelper class where the parmDeactivateMenuName is set to the DirPartyPostalAddressDeactivateVend.

Another example would be the WorkflowWorkList form, which because of the fact that workflows from all over the system are being displayed on one form Microsoft decided the best way to handle this was to stored the menu item needed to see this workflow in the database. So if you look at the WorkflowWorkItemTable (the datasource for the form) you will see a column called MenuItemName. Based on which menu items a user is assigned (and at what access level) will dictate which workflows they can interact with.

Since neither security being done in X++ or stored in the database is captured in the task recording output, it is not really feasible to correctly generate the securable objects that need to be assigned. In this case, it is a manual process to determine the securable objects required when one of these methods is used.

How Can You Address These Issues?

To fix the issues from above I’ve built features into the Fastpath Security Designer tool that address most of the issues described above.

1) Show object access types and license type required for each object

When analyzing, we show object system name, label, and type, the required access type and the license required for this access.

2) Show all menu item types (display, output, action)

We analyze task recordings for menu item outputs:

As well as menu item actions and menu item displays:

3) Show objects that are associated with form controls

This is a comparison where I took the same task recording (recorded myself completing a sales order) and uploaded it to the security diagnostic tool in D365FO on the left and then uploaded it into Fastpath Security Designer on the right. You can see that the missing items are now present within Fastpath because we are able to analyze for objects tied to a form control.

Alternative Solution

I also have a free solution on my GitHub that doesn’t offer all of the capabilities of our Fastpath Security Designer but will analyze all different menu item types as well as work for both AX 2012 as well as D365FO.

Task Recorder Parser

Conclusion

The Security Diagnostics for Task Recordings feature within D365FO is a great tool to start down the path of setting up least privilege security or just determining the access a user needs to perform a business process. But it’s also important to keep in mind that there are some gaps in the native tool that you need to be aware of and what other solutions are out there to help you on your security journey!

As always, if you have any questions about this please feel free to reach out.