Even though almost everyone now completely understands and agrees with the new licensing scheme for Power Apps Portals (right?), I still get questions on it from time to time (or is it all the time?). So, I thought I’d share my own personal interpretation of some of the nuances.

It should go without saying, but it doesn’t, that I am not Microsoft, nor do I work for them, so I clearly don’t speak for them. Nor am I a lawyer. Or a licensing expert. So, reader beware, use my interpretations at your own risk, etc., etc.

A Quick Review of Licensing

Licensing for Power Apps Portals is based on the end users of the Portal. Those users are broadly grouped into three categories:

1. External users (authenticated): pay per login (multiple logins within a 24 hour period count as a single login)
2. Anonymous users: pay per page view
3. Internal users: Portal is an App (like Canvas or Model-driven), and must be licensed like one

Licensing Requirements vs Enforcement

Whenever we discuss Microsoft licensing, especially Power Platform, it’s important to acknowledge the difference between what the licensing requirements say, and how those rules may or may not be enforced from a technical perspective (Team Member licenses, anyone?).

To be clear, I implore you to ensure that you are following the licensing requirements and are not relying on the technical enforcement to ensure you are compliant. Just because you can do something doesn’t mean you should, and that is no defense if you are audited.

Internal vs External User

One of the problems with the Power Apps licensing guide is that it uses terms without defining them. Let’s start with internal user.

The assumption that is easy to make is that internal users are the opposite of external users. According to the Dynamics 365 licensing guide;

“External users are not employees, contractors, or agents of the customer or its affiliates (i.e. a separate company, an independent contractor)”.

Based on that assumption, it wouldn’t be crazy to think that if a company built a portal for its partners to register opportunities that those would be considered external users.

However, this is where you need to think about how Microsoft actually intends to keep track of users in those different categories. Since you’re paying per login or per user, they must be tracking it. How does Microsoft know the difference between internal and external users?

My understanding is that it is based on how the user is logging in. Logins from the Azure AD tenant associated with the CDS/Dynamics 365 instance are considered internal logins. This is true for both regular users, and guest users. Logins from any other authentication providers are considered external logins.

With that being said, it is also my understanding that users that are employed by the customer (or are agents or full-time contractors) must be licensed as internal users, regardless of how they login. So you can’t (or, shouldn’t) simply get employees to login using a social account and then pay for external logins.

What this means is that if, for some reason you want employees to use a Portal using social accounts, you’d need to pay for them twice: in order to be compliant with the licensing rules, they’d need to be licensed as an internal user (though this is not technically enforced), however their logins will still count as external logins, since Microsoft has no way of distinguishing between external or internal users who login with something other than Azure AD, so they count those all as external.

Also, to repeat, guest users in the Azure AD tenant associated with the CDS/Dynamics 365 instance are considered internal users, and must be licensed as so, even if those guests are from outside the company. This is inline with how external access works for other types of Power Apps (Canvas, Model-driven), in that they can have access but must be licensed like internal users.

On the other hand, if you enable multi-tenant Azure AD authentication (where anyone from any Azure AD tenant can login without being a guest), users from other tenants are not considered internal users.

So, in summary:

• I recommend people think of internal users as anyone who works for the company, or will log into the Portal using the company’s Azure AD (even as a guest).
• If you want external users to authenticate using their Azure AD, consider using multi-tenant Azure AD.
• I recommend that you use Azure AD authentication for internal users whenever possible, or you’ll be paying twice.