The Deny permission in D365FO is a powerful piece of functionality that I’ve written about before. But if you want to utilize this feature from the AOT, there are some things to know about and keep in mind to ensure you are correctly configuring this access.
In the AOT
If you are setting up object access within the AOT and want to apply a Deny permission to an object you will need to go to the Access Level parameter and select the ‘No Access’ option.
As an example, of what this would look like I created a test privilege called ‘AMTestPriv’ and assigned the CustTableListPage menu item at a ‘No Access’ level:
What Does This Look Like From the UI?
Once I build and sync the project, what does this setup look like from the front end?
In this case, it will Deny access to the entire object at all access levels (Read, Update, Create, Delete).
What if I Don’t Want To Deny All Access Levels?
If you have a scenario where you would only like to deny a particular access level, this can only be set up from the Security Configuration form in the user interface. For example, if you wanted to ensure that a particular role could not delete customers but did not want to deny all access to customers this could be done with the following setup:
Unfortunately, there is no way to set up this type of security configuration via the AOT.
Conclusion
I hope this post helps to point out how to effectively utilize the deny permission from the AOT and to show potential security scenarios where you may need to also use the Security Configuration form to achieve.
Hi Alex,
I think that if you want to deny delete but enable other operations in your example, you can set the access level to ‘Correct’ at AOT. And only when we need to enable delete but disable update/create, we’ll have to get that done via UI. Is my understanding correct?
Thanks,
Andrew,
In your first example, you are not truly ‘denying’ the Delete access, you just aren’t assigning a Delete access. Which means that if another role, duty, or privilege assigned to the user grants this access the access would be assigned to the user.
But yes you are correct, that if you want to grant and deny access to the same object but at different access levels, that setup must be done via the user interface.