Since I’ve written multiple posts on this topic in the past, I thought it would be a good idea to combine the different posts and create a place that I can continually update with the latest information. So going forward, while I will still have individual posts on user licensing as well, this post will always be updated with the latest information.
Last Updated: 1/25/2021
Where We Started
In AX 2012 and versions of D365FO prior to October 2019, the only licensing mechanism within the system was ‘Entry Point Based Licensing’. In this methodology, each menu item had two separate parameters:
- ViewUserLicense – user requires this license if they are assigned Read access to this object
- MaintainUserLicense – user requires this license if the are assigned Update/Create/Delete to this object
The D365FO license types available were hierarchy based (from highest to lowest):
- Operations (will be listed as Enterprise in AOT)
- Activity
- Team Members (will be listed as Universal in AOT)
You could report on the licensing either from:
- The user interface in the View Permissions area of System Administration -> Security Configuration
- From the ‘View Related Objects and Licenses for All Roles’ report in the AOT.
The licensing model looked like the following:
Where We Are Now
The change that Microsoft made to user licensing in October 2019 was that the Operations level licensing is now broken out by application area into what are now called ‘license SKUs’. There was no overarching license for either Customer Engagement or Finance & Operations, there were different areas within each application that required a particular license.
The way to determine which license SKUs a user is now required to have is based on the privileges the user is assigned. These privileges come from the roles assigned to the user via the role -> duty -> privilege hierarchy structure of the security model.
So now there are two separate licensing models in use currently:
- Entry Point Based Licensing (explained above)
- Privilege Based Licensing
Base vs Attach Licenses
When licensing for a user there are two categories of license: Base and Attach.
And they have the following characteristics:
Base
- Must be the first license assigned to a user
- Must be the highest priced license
- Every user must be assigned a ‘base’ license to access the application
Attach
- Added on to a ‘base’ license
- A user can have as many ‘attach’ licenses as needed
What is Privilege Based Licensing?
Microsoft designates certain privileges to be associated to one or more license SKUs and then determines if that license SKU is required or if any listed license SKU will meet the requirements. This is done from a static JSON file loaded into the LicensingServicePlansPrivilege table.
The PrivilegeIdentifier is the system name of the privilege, the SkuName is the license SKU, and the IsUnique column determines if that particular license is required to be assigned to the user or if any of the license SKUs associated to the privilege will meet the requirements. So an IsUnique value of 1 dictates that a user assigned that privilege is required to have that license SKU either as a base or an attach license, an IsUnique value of 0 means any of the listed license SKUs for that privilege will meet the licensing requirements.
So How Does Entry Point Licensing and Privilege Based Licensing Work Together?
I’ve created a Visio diagram to help with the process of showing how these two licensing methodologies work together:
Reporting Options
User License Estimator Report
This report shows the license SKUs required for each user based on their current access, this report can be found at System Administration -> Inquiries -> License Reports.
View Permissions
The View Permissions report now shows the new licensing requirements, this report can be found in System Administration -> Security -> Security Configuration -> Selecting a role/duty/privilege -> View Permissions.
Also when assigning roles to a user, the License required for that role is shown in the Assign Role to User form:
Resources
Determining User Licenses in D365FO
October 2019 User Licensing Update for D365FO
Current State of D365FO User Licensing for August 2020
Dear Alex,
Thank you for this clear post. Very helpful as a summary of the posts about the licensing. One question however, did you notice a difference of the results on licensing if you ran the User License Count report against the License Estimator report?
For me it seems the results from the ‘view permissions’ and the user count license report are the same, which are different from the needed licenses needed for the Security roles and thus users that have these assigned, if you run the license estimator report or try to assing roles to the user.
Do you also experience these differences, or is this related only to custom roles in the system? I was wondering how the table LicensingServicePlanPrivilege is getting filled. Because if you change privileges, will it also be reflected in this table, and thus in the license estimator report? So the question is how to know the amount and type of licensing needed for your environment if these reports show different results.
Thanks in advance to share your thoughts or ideas on this.
Best regards,
Ken
Ken,
Keep in mind that the User License Count report does not take into account the different license SKUs assigned to a user, it will still list out licenses as Team Member, Activity, Operations. And the User License Estimator report will only show users that require a license SKU be assigned. Are you saying that the number of Operations level users in the User License Count report does not match the number of users in the User License Estimator report?
I guess I haven’t seen that before but it wouldn’t surprise me as Microsoft keeps changing the logic used to determine which license SKUs are required for a user.
The LicensingServicePlanPrivilege table is currently being filled by a static json file, I talk about this more here: https://alexdmeyer.com/2019/12/19/current-state-of-user-licensing-in-d365fo-pu31/
As far as how do you determine which licenses are actually required, I go back to the Visio diagram I created as this is the current logic that should be applied. It’s basically a combination of both entry point based licensing and the new privilege based licensing. If you would like a more automated way to determine the licensing requirements please refer to our Fastpath Access Reviews licensing reports that are available at the user, role, duty, and privilege level that will show the licensing information:
Feel free to reach out if you have any questions!
Hi Alex,
Thank you for this answer. I think it’s as close as we can get to determine the needed licenses. Indeed, I saw a difference in numbers between Operations licenses on the User License Count report and the number of users in the User License Estimator report. But was wondering where this difference was situated.
Thanks again for your explanation above, perhaps we’ll have to create a ticket at MS to support on the numbers coming out of the reports.
best regards,
Ken
Ken,
Once last thing I will say is that there were known bugs in the User License Estimator report from PU31 -> PU39 at least. Not sure what version you are on but Microsoft has continually updated this report throughout their releases. Also would be curious to know if there is any pattern to the users who require an Operations license but don’t show up in the report (are they all assigned a specific role/duty/privilege, or hit some other edge case that the report doesn’t cover, etc)
Hi Alex,
Thank you for this post.
I have customized form and menu item, I set “configuration key” value to control the access. I generated license file and sent it to the client. all user have full access on that form.
now, I want to grant specific users full access on this form, and others read only access. can I achieve this using the license file, or other security options? (security roles will not work, coz they are controlled by the admin).
Thank you very much!
Mustafa,
The license file cannot perform the action you are looking for, they are only meant to enable/disable particular features. If you want to have some users have full access to a form while others have read access, this would have to be done via normal security roles.
Thank you Alex,
is there any way to utilize the ViewUserLicense/ MaintainUserLicense properties of the menu item?
using security roles, admin can add/remove users to that security role, so he has the control. and I need to have the control over how many users can access my form (full), and how many users can access it (read only/ view)
Thank you again.
Mustafa,
There’s no out of the box functionality to be able to achieve what you are looking for, you would have to write some logic within your form to do a custom license validation check.
Thank you Alex,
yes, I can add custom logic to the form. is there any reference or hint that I can check to write this custom validation?
Mustafa,
There isn’t any guide from Microsoft or anything like that, you may be able to find others that have tried and implement something like this but I am unaware of any.
There are a number of different ways to go about implementing this but you would probably need something to have the association between user -> access to your form. I don’t think you would be able to do this live as there is too much role access data to process so you would have to do it as a background batch job and store it in a custom table. And then have someway to report whether the licenses assigned to the users matches their access (if a user has the Read license then they should only have read access, if they have a Maintain license then they can have Update/Create/Delete access). If it doesn’t you would have to have some logic to stop the form init() or throw up an error message or something.
Thank you very much Alex, Appreciate your feedback!