I have a very interesting licensing scenario I recently ran into surrounding using the deny permission. With the move to D365FO, the deny permission allows for explicitly revoking access to an object, this in turn, should also impact the licensing to a user, role, duty, or privilege. To test this I set up the following scenario:

1. I found a menu item that has different licenses for the ViewUserLicense and MaintainUserLiecense parameters, I found the BankAccountTable menu item display. It has a MaintainUserLicense of Operations and a ViewUserLicense as Universal (Team Member). This means that a user/role with Read access to the BankAccountTable menu item will require a Team Member license and a user/role with Update, Create, or Delete permission to this object will require an Operations license.

2. I created the following privileges

1. • One that grants full control to the object – FPFullAccessBankAccount
   • One that denies all access to the object – FPDenyAllAccessBankAccount
   • One that denies Create, Update, and Delete to the object – FPDenyCUDBankAccount

3. Assign these privileges to a role in different combinations and then validating the results in the View Permission report as well as the User and Role licensing reports

Scenario #1 – Assign FPFullAccessBankAccount privilege to role

As expected, the license type required for the role is Operations.

Scenario #2 – Assign FPFullAccessBankAccount and FPDenyAllAccessBankAccount to role

Also as expected, if you deny permission to this object this role will no longer require an Operations license.

Scenario #3 – Assign FPFullAccessBankAccount and FPDenyCUDBankAccount to a role

The combination of these privileges assigned to the same role will make the comprehensive access to this object to be Read. I would have expected this combination of access to then require a Team Member license but it appears that D365FO is reporting this role to require an Operations license.

Conclusion

So there are two options:

1. This is a bug and the deny permission should be taken into account with determining licensing but is currently not
2. This is not a bug and unless you remove the access entirely, D365FO only looks at the Grant access to the object to determine licensing

With the difference in pricing between an Operations level license ($190 user/month), Activity ($50 user/month), and Team Member ($8 user/month) the monetary impact of this can be quite large. In any case it is important to keep this in mind when trying to modify your security to control license requirements.

Note: I also repeated the tests above only granting Update and Create access to the object and the results remained the same, just in case the rogue Correct grant access (there is literally no way to deny this access from the AOT or UI without denying access to the object entirely) was causing erroneous results or different levels of access caused different outcomes.