How to Read and Analyze the Dynamics 365 F&O License Usage Summary Report – A Real-Life Scenario
How to Read and Analyze the Dynamics 365 F&O License Usage Summary Report – A Real-Life Scenario
License management has now become a necessity in Dynamics 365 ERP applications. With Microsoft’s license enforcement process, which will come into effect in November 2025, every menu item, role, and task accessed by each user in the system must be matched with the appropriate license type. Otherwise, companies may face unnecessarily high licensing costs.
So, what should system administrators or consultants do in this process? At this point, the newly introduced “Licenses Usage Summary (preview)” report by Microsoft becomes critically important. Now, license requirements can be analyzed in detail — not only based on the user’s assigned role in the system, but also by diving into which duties, privileges, and menu items (AOT) are accessible through that role. With this report, we can analyze which licenses a user needs and which roles are responsible for those needs.
In this article; We will examine the “Licenses Usage Summary (preview)” report, which is part of the new Security Governance framework, in detail through an example user. We will also review how to interpret license distribution based on specific Duties, Privileges, and User Roles.
You can access the report from: System administration > Security > Security governance > Licenses usage summary (preview). You need to be on version 10.0.44. Additionally, if it is not already enabled, you must activate both “Security Governance” and the report separately through Feature management.
Resim 1
Once activated, you will be able to see the module and the report in the menu.
Resim 2
Tab Structure — Here, we summarize the main tabs of the report, and later we’ll examine them in detail through an example.
- User Licenses → Shows the licenses required based on the roles assigned to each user in the system.
- User Role Licenses → Displays User ID, the roles assigned to the user, and the license type associated with each role.
- Role Licenses → Allows analysis based on roles. Shows which SKU licenses correspond to a role, along with all its duties, privileges, and AOT components.
- Duty Licenses → Displays which licenses are required for specific duties. For example, you may see that the “Maintain Field Service Parameters” duty requires both Project Operations and Finance licenses.
- Privilege Licenses → The most detailed level, this tab shows which AOT elements each privilege gives access to, and which license this access is associated with. The Maintain project parameters privilege grants access to the ProjStatusRuleSetup and ProjParameters forms, which may be what triggers the requirement for a Project Operations license.
Throughout this article, we will be analyzing the user named Zeynep. As seen in the image, there are three different license requirements. The primary license is Finance, with additional needs for Project Operations and SCM as Attach licenses.
Due to the roles assigned to Zeynep, she has access to a total of 7163 objects — 6905 through Finance and 258 that require additional licensing. We can express it this way, even if not perfectly literal. With the Finance license, Zeynep can access 6905 of these objects, but for the remaining 258, two other licenses are required. Two of them specifically require a Project Operations license, while the remaining 256 objects require the SCM Attach license.
Let’s now break down what the three grids shown in the report actually represent — one by one, in detail.
Resim 3
The data in the first grid comes from the LicensingUserDirectLicenseAssignments view. Let’s open and examine it using the Table Browser. In fact, it contains the same information we see on the screen — values like UserRecId and SkuRecId. These indicate the user and the license type.
When we check it again using Zeynep as an example, we can see the exact same data reflected here as well.
Resim 4
The second grid on the right comes from the LicensingUserRequirementsSummaryView. Here, I filtered Zeynep’s RecId. In this view, we can see how many objects are covered for Zeynep by each license type. For our example, this is not a critically important dataset. I don’t think this will be very useful either. Perhaps one could make deductions like “If I get Finance Premium instead of Finance, I can cover more objects,” but I haven’t come across such a case yet.
Resim 5
Now let’s move on to the main view where license requirements are revealed: LicensingUserRequirementsDetailedView. Again, I filtered the data for Zeynep. This table can contain a lot of records because it is duplicated by license type and can include thousands of rows — all generated based on the roles assigned to the user.
Resim 6
So far, our analysis is sufficient. Now let’s move on to the scenario. I believe Finance and SCM Attach licenses should be sufficient for Zeynep. To understand which objects are triggering the need for a Project Operations license, we need to do some investigation. I exported the LicensingUserRequirementsDetailedView for Zeynep. First, I filtered out the rows marked as “Not Required.” From the LicensingUserRequirementsSummaryView, I found that the SkuId for Project Operations is 8. I then filtered this ID in the detailed view. Of course, this results in thousands of rows.
What I’m actually looking for are two records that are not entitled by Finance or SCM, but are entitled only through Project Operations. There are several ways to find these — you could write a query or use role details from other tabs. But since I got a little lazy, I asked AI. I uploaded the file and asked the question, and got my answer below. We found the culprits. So, which role is triggering these? Let’s check that in the next tab.
Resim 7
In the second tab, we can again see the roles assigned to Zeynep and the license types required due to those roles. Since there’s only one entry requiring Project Operations, we quickly identified the role: Field Service Integration Admin. When we look at the details, we can see the two offending objects and another unrelated one. Now that we’ve identified the role, let’s examine its details in another tab.
Resim 8
We filtered the Field Service Integration Admin role. Let’s interpret the row shown in the image. For this role, the Finance license covers the ProjBudgetUserGroupSetup object, but it does not cover the other two. However, if you look at the Project Operations row, you can see that all three objects are included. This is why Zeynep requires the Project Operations Attach license.
Resim 9
We can examine this role in more detail using the Security Configuration form. When I open the role, I see that it includes the duty Maintain Field Service Parameters.
Resim 10
As I open the details, I can see which objects are included at the lowest level.
Resim 11
I open the duty Maintain Field Service Parameters from the Duty Licenses tab and filter it. I encounter a structure very similar to what I saw in the role. Since the number of objects is low in this example, it’s easier to interpret — but for more complex duties, you’ll need to dive deep into these lists.
Resim 12
Similarly, I filter the privilege Maintain project parameters that I found. Again, I see a very similar layout.
Resim 13
As a result, I decided that removing the Field Service Integration Admin role was necessary to eliminate this license. So, I removed the role. Here’s the final version of Zeynep’s roles. These changes don’t appear immediately in the report. When I checked the next day, I saw the result below.
Resim 14
The next day, I was able to see the desired outcome. Now, Zeynep can continue her work with just the Finance and SCM Attach licenses.
Resim 15
In this article, we examined with examples the screens and analysis methods you can use to understand and align with licensing processes in the Dynamics 365 ERP system.
Conducting these analyses before the mandatory license assignment enforcement comes into effect in November 2025 is critically important for ensuring smooth system operations and managing license costs effectively.
The transition to a per-user licensing model and the introduction of mandatory auditing mechanisms now require ERP system administrators to approach license management more proactively. We especially recommend that companies with a high number of users start this work immediately and, if necessary, manage the process with the support of their Microsoft partner.
Remember: assigning the right role to the right user is not only essential for system security, but also a vital step for licensing compliance.
Best regards,
www.fatihdemirci.net
TAGs: Licenses, Security, PPAD, LCS, Dynamics365, MsDyn365FO, LicenseCompliance, SecurityGovernance, ERPcosts, BusinessApplications
