One new piece of security functionality in D365FO is the idea of having an explicit deny access level available to assign. I’ve written about this access level permission in the past and how it overrides any other grants made to this object when assigned to the user. This functionality did not exist in AX 2012 so the question is ‘How do I utilize deny permissions when setting up security?’

When to use Deny?

It isn’t always straight forward when to use the deny permission. Even if you are using task recordings to help set up security, this process will not identify when to use the deny permission to achieve your end goal as it is only looking for menu items consumed during a recording and you cannot designate certain functionality to be denied.

The easiest way to determine if you should be using this deny functionality is if you think ‘I need this user to be able to access this form but not be able to do [this]’ then it might be a good candidate for using the deny permission.


One scenario I hear often is that a company wants a user to be able to have full control (Delete permission) to the sales order lines but not be able to modify the actual sales order header record. So the first thing to do is to take a task recording of you performing the task of modifying, creating, and removing a sales order line from a sales order. When you analyze this task recording in D365FO you get the following menu items:

If you take this task recording to Fastpath Security Designer you will be able to see the access types and licenses required for each menu item:

But when you launch a test workspace with this security, you will see that a user assigned these permissions will have the ability to create, modify, and delete the actual sales order as well:

So we need to find a way to lock down that part of the process.

The first thing we need to do is determine the data source of the form we are trying to secure. By right clicking on the form, we can get the detailed information on the form and see that the SalesTable is the data source driving this form.

Then we need to determine which actions we want the user to not be able to perform. In this case, we don’t want to the user to be able to Update, Create, or Delete the actual sales order. This is where adding the Deny permission comes into play. We must first apply a Deny access level permission to the Update, Create, and Delete access type permissions to the SalesTable via the Security Configuration area within the user interface. This change must be done via the user interface as there is no way to Deny individual access types like this in the AOT.

Now when we re-run the test from earlier we can see the user still has the ability to modify the Sales Order Lines but does not have the permissions necessary to modify the Sales Order Header.

So the final resulting security to get this set up looks like the following:


The Deny security functionality is very powerful, and I recommend that all users upgrading from AX 2012 look at places where they could maybe simplify their security setup to use this new feature. Hopefully this walk through helped show how to use the Deny access level in your security design. As always if you have any questions feel free to reach out.