Licensing Advent Calendar – Day 14 – Custom security

Two weeks a post a day. It is incredible how much detail you can write about this topic. Today, I will talk about scenarios I have seen at clients over the past year and before.

Security implementation

The number of clients is almost equal to the number of different implementation scenarios I have seen. The variation is between having a full access role per license, roles per job role, roles per user, and roles per sub-process. Sometimes roles per job-role are duplicated to have a slightly different implementation per legal entity. For actual roles in use, there was a difference between 8 and 542. All, including the system administrator and system user roles. When mentioning the first number, this is an example where there was a lack of time for creating roles, and they did not take Segregation of Duties into account. Having 542 security roles in use, it will complicate the maintenance of users with the role assignments. This complication also brings additional risks where you can assign the wrong role or forget about the organization assignments.

When talking about clients with custom roles, there are three main approaches I have seen.

1. Creation of new roles and adding existing roles as sub-roles
2. Creation of new roles and reusing standard duties and/or privileges
3. Creation of new roles and creating new duties and/or privileges.

Personally, I don’t like the first approach. In attempts to provide a user with the permissions they need, I have seen scenarios where there were 5-14 or sometimes more sub-roles linked to the custom-configured roles. This is for sure the moment where, without license awareness, the user may need 3 or 4 different licenses.

The second approach is the one I prefer. Reuse the security elements as much as possible and only create new duties and privileges when you need to fine-tune access permissions. Yes, I’m aware that a user will get, e.g., reports available that he doesn’t need. In case the menus are not overwhelming and there is no risk of granting access to these reports, this is quicker than option 3. The privileges usually have related securable objects implemented, also including table or form control permissions. In addition, some duties might require a different license than the one you are creating the role for. In that case, you can create a copy and remove elements that are not required for the role.

Using option 3, they either use the task recording, ISV solution, create privileges from scratch, or copy existing elements and make changes. Using the task recording or ISV solutions supports the creation of new privileges, making the process of security implementation for non-experienced users easier. The naming convention usually used for these privileges does make audits more complex.

Common examples

In this section, I will mention some examples where the actual license requirement was higher than the expected license.

Purchase requisitions

The creation and approval of purchase requisitions do require the Team members license only. In the standard application, this is part of the out-of-the-box Employee role. In several cases, there is no need to have all features of the Employee role available to your users, and this makes the creation of a specific role for purchase requisitions a legitimate approach.

In several cases, the purchase requisitions role got additional features, making it an Operations – Activity, or Finance license. E.g., if you add the option to receive goods, this is not a Team members license anymore. In this case, you can split the role and provide the receipt of goods only to a select number of users instead of, e.g., all.

Timesheet and invoice approvals

When Microsoft started with the new licensing calculation, several objects related to the use of timesheets, purchase requisitions, and approvals did not have the license requirement as stated in the Dynamics 365 licensing guide. This is corrected in the most recent updates. Still, in case you have an incorrect license requirement, you need to verify the details and see if this is still a bug in your environment or if there are elements included that actually belong to a higher license SKU.

Read-only roles

The creation of read-only roles is popular and is used for many scenarios. Due to unawareness and not having licensing insights at the moment these roles were created, I have seen many times that there was a requirement for, e.g., two base licenses. This is mainly due to copying or reusing standard privileges and/or duties. Yesterday, you could read that there are errors in standard security objects. In the past, there were more errors you could have copied along. In case the role should be read only, then check which securable objects are not entitled and check for the access level. Changing the permissions from write to read-only should solve the issue for these roles quickly. In one scenario, I found out that a read-only intended role was granting permissions to confirm, deliver, and invoice sales orders.

Copy standard elements

This is a bit of duplicating the previous heading. There are some incorrect permissions granted on standard security elements. The number of error were larger in the past. In case you are reusing standard security duties and privileges or copied them, there might be, e.g., maintain privileges part of inquiry duties or write access on view privileges. These all can cause higher license requirements. They aren’t usually noticed in standard security roles when they are intended to have a Finance or other base license requirement. When we reuse them in our security implementations, they can be noticed. In case you come across an incorrect object, you can create a support ticket for Microsoft, but the process to get it sorted and released takes weeks or months. It is still recommended to create a support ticket for improving the overall product, but to have it corrected quicker, can duplicate it yourself and make adjustments.

There is more…

During the Advent period, each day in December, I will share some thoughts and tips related to the Dynamics 365 user license enforcement. If you have questions about this topic, feel free to contact me via LinkedIn, the comments section below, or the contact form on this blog. I will then either update one of the planned blogs for the coming 24 days or answer questions in a new post.

Dynamics 365 Licensing Enforcement Advent Calendar

I do hope you liked this post and will add value for you in your daily work as a professional. If you have related questions or feedback, don’t hesitate to use the Comment feature below.


That’s all for now. Till next time!