Security in D365 F&O is best described as a hierarchy of how permissions are grouped and rolled up into security roles, which are assigned to users.D365 F&O security takes a least restrictive approach to security. A user will have the highest level access to each menu item, even if access is granted through one or more role, duty, or privilege. At the base of security are privileges.

Privilege are where access to individual menu items, tables, reports, or running specific processes is granted a certain level of permission into the system. Each access point, or securable object, is granted either Unset, Grant, or Deny permission to each level of access-read, update, create, or delete. Grant access is pretty straight forward--you have this access. Unset is a bit more vague, but within D365 F&O, security granted is a cumulative combination of all access points within all security roles assigned to a user.  By leaving a securable object as unset, you are not granting or denying access through a this particular privilege. One privilege may grant read access, but leave update, create, and delete unset. If another privilege that is assigned to the user has grant access update, create, and delete to the securable object, the user will have full access to that particular object.

Deny permission doesn't mean what you think it might.

Deny permissions are not the opposite of grant. When we look at the security as least restrictive, one could assume that deny is less restrictive than grant, so a user will be granted that access when the access is combined. Wrong. 

Deny permissions are the gate keepers- you shall not pass. Once a user has been assigned security where a securable object has any form of deny permissions assigned to it, that user will never be able to gain that level of access back again, unless that deny access is removed or they are granted System Administrator access. Since the latter is never a feasible option in production instances, the only option is to change their access completely.

Imagine this scenario--a user is granted role A, which has permissions full grant permissions to general journals. This user can see, create, update, and delete general journals. Then one day, someone realizes that certain users should not have access to see general journals and even seeing the journals is considered a risk. Upon reviewing the security, they noticed there is a custom privilege that is used to grant read access to general journals and this privilege is assigned to the roles of all the users that should not be able to see general journals. A change is made to select Deny permissions on read access of general journals is published. What the review failed to reveal is that all the users that had access to create, update, and delete general journals were also assigned this privilege. Since deny is the gate keeper, role A no longer has access to view general journals. While users of role A may have had update, create, and delete access to general journals, if they cannot see them, that access is useless. Until the deny permission is removed, users will never be able to access general journals.

As you can tell from our example above, this deny access that was meant to secure data actually halted the accounting department.  There are risks associated with using deny permissions, with business disruption being the most critical. The severity of impact will depend on the level of access set to deny and the types of securable objects used. 

When a deny permission is not properly placed or accidentally used in the place of unset to omit access through this privilege, consequences can quickly pile up and require immediate correction to avoid major negative impacts to your business.

Why would we be given the option to deny access if it is so invasive and I just told you some worst case scenarios of using it?

The answer is simple--Sometimes you don't want users to be able to do something, no matter what. One example that comes to mind is the ability to delete sales orders. In environments where sales orders may be created as orders are placed on a website and then are created in D365 automatically, deleting a sales order could cause issues. If the process of rejecting a sales order is to cancel it, but no sales orders should be deleted, a deny permission would be necessary. By creating a privilege where the Delete access is marked Deny, but all other access levels are given grant permission, users can create, update, and view sales orders, but they cannot delete them. 

When used properly, deny permissions can assist in ensuring standard operating processes are upheld. The most important part of using a deny permission is to make sure it is configured as seperate from non-deny permissions as possible. In our example above, the ideal configuration would be to create a privilege with the word deny in the name, such as Deny sales order delete. This privilege should be assigned to a duty with a similair name. This duty could then either be added directly to a role containing other duties that grant access, or held in its own role entirely. The key is to be able to quickly remove the deny access when it becomes a problem to standard processes, and to be able to tell exactly where the deny permission is housed. In a system where users are typically assigned access to thousands of securable objects, looking for a deny permission doesn't need to be like searching for a needle in a haystack.

When you do need to implement deny permissions, be sure to thoroughly test in a non-production environment first to ensure no adverse impacts will be present when implemented in production. The key is to use Deny permissions sparingly and not use them as a radical approach to lock down access in D365 F&O. When it comes to deny permissions, less is best.