Licensing Advent Calendar – Day 6 – Excluded users
In the post for day 6, I will give an introduction to users that are excluded from the User licensing reports on Power Platform Admin Center (PPAC), Lifecycle Services (LCS), and on the User Licenses Summary page in Dynamics 365 F&O.
Excluded users
On day 4, I explained that the license calculation is a microservice running outside of the Dynamics 365 application. The calculated data is a single source from where a license report in the Power Platform Admin Center (PPAC), LCS, and licensing data in Dynamics 365 F&O are fed.
In the past two days, I talked about available User License Consumption reports available in PPAC and LCS. One of the tiles is recently added to the report and is showing the users without a license requirement.
When you click on the tile, you will get a list of users excluded from the report.
There can be various reasons why the users are excluded from a license requirement:
- System administrator
- Integration user
- Device user
- Vendor collaboration user
- Applicant user
You can click on each of the names to see reasons per environment.
The users are excluded when they have particular roles assigned which is listed in a document named User Security Role Reporting and Technical Validation for Dynamics 365 Finance and Operations Apps – FAQ
Reporting versus license compliance
There are some additional conditions that is important to realize. Despite the users are excluded from the report, it depends on what exactly will be done by the users with these roles. E.g. the system administrator role is for the purpose of performing administrative tasks, like maintaining batch jobs, enabling users, etc. In case a person will perform daily tasks that should be done by normal application users, the user which is excluded from the report officially needs a license. This is visible in telemetry.
Device versus device user
Device licenses are to be acquired in case hardware is shared by operations users and limited to the scenarios covered by the Dynamics 365 licensing guide. There are devices listed in the guide for the purpose of e.g. warehouse mobile device, POS, and Manufacturing execution. There is no option today (December 6, 2025) to assign a license to a device. This is on the roadmap to be added next year. Engineering is required to make that possible. Each of the devices is having an integration with Dynamics 365 F&O and are using an application user for the device connection with the business logic and the data. Users are set up in the application with specific roles to limit access to only the features supported by the device. E.g. the role Warehouse mobile device user is used for the warehouse device connections.
There are scenarios that your device user will be listed on the report. In tomorrow’s post, I will elaborate on that and explain what you can do to avoid having these users included on your licensing reports.
Other excluded users
There are more users excluded from the report. For example, in case users are disabled, they don’t show up on the report. In case you want to check for user license requirements in a non-production environment, then you will need to have the users active.
In the Dynamics 365 licensing guide. there is a special section about external users not needing a Dynamics license and under what conditions. One example is the vendor collaboration where contacts from your vendor will have access to purchasing data as part of a portal access. These users will read data and can respond to changes by e.g. reviewing the purchase orders.
For external users, usually, there is no direct access in the application itself. They will have access via Power Apps or Power Pages with limited functionality. For these scenarios, Power Platform licensing is required.
A frequently asked question is about external consultants having access to Dynamics 365 F&O as system administrator. Yes, these are also external users and are excluded from the licensing reports in case they have one role as listed above, e.g. the system administrator role. Using this role, they can help with setting up the application or performing some troubleshooting.
My opinion is that, when possible, the base setup and troubleshooting should be done in a non-production environment. It is a huge security and compliance risk to have external users set up as system administrator in a production environment. As this role is bypassing all security, the external consultant have access to all sensitive data.
These environments are excluded from license requirements as well, despite the reports will show the users and their roles in all Microsoft managed production and sandbox environments.
In case an internal or external system administrator investigated why a posting was giving error, they can change settings and perform the posting themselves. Preferably, they still should not post the document, but leave that to the user responsible for that task.
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!
Arek Socha from Pixabay
”It is a huge security and compliance risk to have external users set up as system administrator in a production environment.”
– But isn’t this just the reality in most cases and thinking otherwise is naive? There is rarely the expertise to rely only on internal (employed) users to maintain the system…
Hi Rikard,
Thanks for your comment. What exact maintenance are you referring to?
When a customer is live, the maintenance is operationally about e.g. maintaining users and investigating issues reported by users. Next, you need to update the system where regression testing is required and new features can be evaluated. For regression testing and evaluating new features, someone doesn’t need access to a production environment.
If you look at what would be the best, is not providing access as system administrator to a lot of people. It should be limited and do you want to expose private contact details to external people? You are correct that there is a reality today. In my opinion it is naive to not think of proper security. Some companies are subject to strict regulations, like GxP. Also don’t forget privacy laws, like GDPR.
In case there is an issue reported, indeed internal users might not having the skills to find the culprit. Why not creating a copy of the environment (with anonymized private and sensitive data) where an external consultant can do troubleshooting and at the end, let an internal user apply changes in production? Of course, there can be scenarios where issues are to be investigated in production. This should be an exception instead of common practice and you can think of a firefighting access (aka break-glass) request in case someone needs to have temporarily access to the production environment with system administrator privileges.
Let’s change the current reality. External consultants can help in most cases in non-production environments. With proper instructions after an investigation or evaluation of new features, an internal user can make setup changes in the production environment.