What is an Application User?

[IPC_ahaas]

Manage application users in the Power Platform admin center - Power Platform | Microsoft Learn

(https://www.microsoft.com/videoplayer/embed/RWJBr8)

This video does not match the current experience.

Video

Reality

From Environment settings, you cannot click on Security Roles, select a Role, and then assign a user to it.

Why do I need to assign an app to a user? Isn't that the entire point of assigning a user to an Environment (not that that works at all), so they can access the applications within the Environment???

What!? What is a "Microsoft Entra–registered application"??? How is that different than a regular application?

https://learn.microsoft.com/en-us/power-platform/admin/manage-application-users?WT.mc_id=ppac_inprod...

I'm tempted to just go back to sharing apps out of the Default environment like we've been doing, and deleting every environment I've made trying to ALM working. This is just madness to me.

[Amik]

@IPC_ahaas do you understand the difference between a regular user of an application e.g. a canvas app in your environment, and an Application User and/or System user?

[proximacentur]

Greetings,

 Application users are generally used as an alternative method of connecting to and accessing applications and data within the Power Platform. Specifically, these types of users use client secret authentication sometimes called OAuth2. The main benefit of this is if you have automation or some resource you need to access you don’t want to use your personal credentials. Users leave organizations and this can break connections, etc. You mentioned ALM as well. When setting up your Azure Dev Ops pipeline you use application users for security and to ensure that the connection is not subject to be broken based on a user’s account. (application users do have certificates and those can be a point of breakage).

Question:

Why do I need to assign an app to a user? Isn't that the entire point of assigning a user to an Environment (not that that works at all), so they can access the applications within the Environment???

Answer:

The reason for this is because sometimes environments will contain multiple applications sometimes with different data sources and permissions for those data sources. For example, some SQL connections have implicit sharing permissions meaning as soon as an application is shared with a user they have access to the data source, and technically can interact with it (Currently there is a preview feature to patch this). Additionally, you may have applications that have confidential information, etc.

Solution:

To make this as automatic as possible I have tied security roles and users directly to teams within the platform. You can use teams to automatically assign users security roles and get access to applications. You can use Office 365 teams or Azure Security Groups.

(https://learn.microsoft.com/en-us/power-platform/admin/manage-teams)

Question: What!? What is a "Microsoft Entra–registered application"??? How is that different than a regular application?

Answer:

The distinction here is Microsoft is referring to Entra but this is just a rebranding of Service principal, application user, etc. They are more or less the same when it comes to Power Platform. Essentially Entra ID is the unique code assigned to users(could be a real user or service principal) within Azure. When creating a service principal in Azure they will get an Entra ID. This allows other Microsoft products and some third-party products to interact with the user account. The yellow text in the screenshot is calling out the fact that you cannot duplicate an application user within an environment, i.e. “XYZ service principal” cannot have two records in application users within Power Platform.

[IPC_ahaas]

I do not.

[IPC_ahaas]

---

@proximacentur wrote:

Application users are generally used as an alternative method of connecting to and accessing applications and data within the Power Platform.

---

I already don't want anything to do with it then. We shouldn't need an "alternative" just to set things up from scratch.

---

@proximacentur wrote:

The main benefit of this is if you have automation or some resource you need to access you don’t want to use your personal credentials.

---

We have service accounts for that.

---

@proximacentur wrote:

When setting up your Azure Dev Ops pipeline you use application users for security and to ensure that the connection is not subject to be broken based on a user’s account. (application users do have certificates and those can be a point of breakage).

---

I already have a pipeline built and working, though I cannot see (don't know where to look) if it has any ownership on it. Either way, we'll cross that bridge when we come to it. We're trying to get the most basic part of app access working and it's been a nightmare.

---

@proximacentur wrote:

The reason for this is because sometimes environments will contain multiple applications sometimes with different data sources and permissions for those data sources. For example, some SQL connections have implicit sharing permissions meaning as soon as an application is shared with a user they have access to the data source, and technically can interact with it (Currently there is a preview feature to patch this). Additionally, you may have applications that have confidential information, etc.

---

This is exactly what we WANT. You have access to the Environment, you get the app. NO WHERE in Microsoft's infinite documentation does it mention the need to share an app after a user has access to the Environment where the app lives. Truly maddening. So, if this is the case that we must share the app to the user after adding them to a Security Group and assigning them a Role, then so be it - but it's put a sour taste in my mouth for all of this when we were running at full steam out of the Default Environment. Ignorance is bliss.

---

@proximacentur wrote:

To make this as automatic as possible I have tied security roles and users directly to teams within the platform. You can use teams to automatically assign users security roles and get access to applications. You can use Office 365 teams or Azure Security Groups.

(https://learn.microsoft.com/en-us/power-platform/admin/manage-teams)

---

The hell... this is exactly what I'm talking about. A "Microsoft Dataverse team", not a "Microsoft Teams team". Is that what "Teams" are in an Environment? Or is that a third kind of "Team"? And what the hell are "group teams"? A fourth kind of team? Never mind, I don't want to know.

"Using Microsoft Dataverse teams is optional. However, [Microsoft Dataverse] teams provide an easy way to share business objects and let you collaborate with other people across business units. Although a [Microsoft Dataverse] team belongs to one business unit, it can include users from other business units. You can associate a user with more than one [Microsoft Dataverse] team."

I hate all of this. They reinvented Security Groups.

I have a Security Group of people who could use any number of apps within said Environment. If I have to share the app on top of that (groan), fine, but I'll do so with a Security Group as well "SG App Name" or whatever. No need for "Dataverse Teams".

---

@proximacentur wrote:

The distinction here is Microsoft is referring to Entra but this is just a rebranding of Service principal, application user, etc. They are more or less the same when it comes to Power Platform. Essentially Entra ID is the unique code assigned to users(could be a real user or service principal) within Azure. When creating a service principal in Azure they will get an Entra ID. This allows other Microsoft products and some third-party products to interact with the user account. The yellow text in the screenshot is calling out the fact that you cannot duplicate an application user within an environment, i.e. “XYZ service principal” cannot have two records in application users within Power Platform.

---

Pretty sure we won't have anything to do with that either. I am the sole app developer, Environment manager, app deployer, etc. Users just need to find the app on their phone or tablet and use it.

[IPC_ahaas · Accepted solution]

Sharing an Environment grants access to data in said Environment. Granting access to Apps is separate.