Power Platform licensing may still look like a beast sometimes, though it’s, probably, a tamed one now. Still, you would not want to tease a beast, and it’s a bit of the same with the licensing. There are a few simple mistakes to avoid, and there are probably more (but I’ll add them to this post if / when I run into them )
Here is my list.
Assuming we can use any available feature
Technically, that assumption is correct. Practically, it may be costly since some of the required licenses are not cheap. Examples:
- Power pages will cost you, at the lower volumes, $75 per 500 unauthenticated users and $200 per 100 authenticated ones per month. So about $300 per month is your entry point, and it only grows from there. Don’t use it for the personal blogs.
- Power virtual agents start at $256 per 2000 sessions. Unlike with the power pages, the same user may consume multiple sessions at any period of time, and they will all be counted. So, perhaps, it’s not 2000 users, it’s probably less. May still be manageable, but keep that in mind.
- If you end up using restricted tables in your solution, you’ll have to go “level up” from your regular Power Apps licenses: https://learn.microsoft.com/en-us/power-apps/maker/data-platform/data-platform-restricted-entities
Not recognizing the difference between internal / external users (multiplexing)
There is one key point about the internal users, which is that they need to be licensed to access Dataverse no matter if they are only going to use Dataverse data through the API-s, or if they are going to enjoy all the benefits of the Canvas / Model-Driven applications.
Also, they need to be licensed for the required first-party applications if they are using restricted tables somehow.
- There is a web site where users from all around the world can create customer service cases in your D365 environment (through the web site UI which would be using web api-s etc). This is where that web site will likely be using an application service account to access D365. Strictly speaking, if someone from your organization goes there to that web site to submit a case, that person would need to be properly licensed. Technically, there would be no issues if there were no license assigned. However, from the licensing perspective, it would be considered multiplexing. Then again, whether you would be able to argue that, in this particular example, your company employee was acting in the “client” capacity and whether that eliminates the multiplexing scenario… just make sure to run this kind of scenarios by Microsoft to avoid costly mistakes.
Not recognizing different authentication methods in Power Pages
This one is relatively simple, but, still. If you have Power Pages, you pay per authenticated/unauthenticated users, but Power App / D365 licenses may cover that kind of usage. It will only be covered, though, once Power Pages are able to recognize such users, which means these users will have to use Azure AD authentication when logging in.
They used Google to authenticate? That’s going to be counted against power pages per-login licensing. It’s the same with Facebook authentication, and it’s the same with any other authentication method other than with the Azure AD.
Assuming access to D365 environment requires users to be on D365 licensing
So far, at least, that’s not the case. Power App users can use those environments, and they can even read from the restricted tables:
The quote above is from the Dynamics 365 licensing guide.
Finally, trying to guess licensing rules instead of looking them up in the licensing guide
Just google “D365 licensing guide” and/or “Power Apps licensing guide”, and you will be presented with a couple of long, somewhat boring, but very detailed licensing guide documents. They may look intimidating, but they can be very helpful, and, at the very least, they may be able to point you in the right direction.
As of today (March 18, 2023), here are the links: