This is a follow-on from from my previous post Power Platform Environments Demystified and If not already done so, I recommend reading that article before this one.
In this post, I’ll cover the different ways an app can be shared with users. Apps can be shared individually with a user or shared collectively using a security group. In this post, I’ll focus primarily on canvas apps. The process for model-driven apps is largely similar, but I’ll highlight all the differences between the two in a later blog.
To share an app, security roles will need to be assigned. This can be done at the time the app is shared, or the security roles can pre-assigned to users or security groups. Pre-assigning security roles can be useful, because it has the benefit of removing the necessity of assigning security roles at the time the app is shared.
Before we start, let’s quickly re-cap on security groups. As I covered in the earlier article. A security group is simply a collection of users who require the same access to a resource. Security groups are created in the Entra Admin Centre and can be used tenant-wide and are not specific to a particular environment.
In the earlier article, the security groups I discussed were assigned to an environment. The purpose of applying a default security group to an environment is to restrict top-level access to the environment. All users have to be in the default environment security group to even access the environment. The security groups I’m covering in this article have a different purpose, to manage which users have access to individual Power Apps.
App Sharing
The first thing to say is that Admins can decide who they want to be able to share apps. This may be the app maker. Alternatively, the app maker may be restricted to the development environment and not be given access to the test or production environments, in which case an environment or tenant Admin would perform this function.
There are good reasons why this may be beneficial. App Makers may assign inappropriate security roles to users or security groups, rather than creating a custom security role, either because it’s quicker/easier or they don’t understand individual security roles or how they work. This goes against the security principle of least privilege (PoLP).
I’ll explain later how security roles can be pre-assigned to a user or security group thus removing the need for the sharer to specify security roles.
It’s also possible to give App Makers access to an environment to build apps, but prevent them from sharing them, and to make this an Admin only role too, and I’ll cover how to do that in a future article.
1) Sharing an App with an Individual User
The easiest and the most common way to share an app is directly with a user and assign the required security roles during the sharing process.
When sharing an app this way, the Admin or App Maker is responsible for assigning the security roles. When sharing a Canvas App, the Maker can assign any security role in the environment. With a model driven app, the security roles are first assigned to the app, and then one or more of those assigned roles are allocated to users when the app is shared with them
The relationship is shown below. When the app is shared with a user, the user has one or more security roles assigned
2) Sharing an App with a Security Group
Sharing apps with a small number of individuals is fine, but once you get above a handful of users, it’s much better to share apps with a security group.
Sharing an app with a security group makes adding or removing user access straightforward, as it is as simple as adding or removing users from the security group. The capability to add or remove users from security groups is not usually given to App Makers and is an Admin role perfomed in the Entra Admin Center. This approach simplifies and streamlines the process and helps separate the role of building an app from the ongoing role of user management.
The process for sharing a Canvas App with a security group is the same as sharing with an individual user, the Maker assigns the security roles at the time of sharing. With a model driven app, one or more of the security roles assigned to the app are allocated to users when the app is shared with them
The relationship is shown below. Similar to option 1, when the app is shared with a security group, the group has one or more security roles assigned. Note that the security group exists at a tenant level, not at the environment level, so it isn’t denoted as a table.
3) Assigning Security Roles to a Security Group Via a Dataverse Team
This approach is a little more complex, but also the most flexible. The security roles are pre-assigned by a tenant Power Platform Administrator, or an Environment Maker/System Administrator of the environment.
In the Power Platform Admin Center against the particular environment, a team is created and a security group is assigned to the team. Security roles are also assigned to the team, so the members of the security group gain the team’s security role privileges.
Think of a team as an intermediate table between the security group and the security roles – which is pretty much exactly what it is.
The other concept that takes a bit of ‘getting your head around’ is that there is no need to add users to the team. The users are only added to the security group. The team is simply the means to connect the security group to multiple security roles.
Using this method, a Canvas App or Model-Driven App can be shared with a security group with pre-assigned security roles. It’s worth mentioning that when sharing a Canvas App with a security group, the sharer still has the option to add additional security roles. With a Model-Driven App, the sharer can also assign additional security roles, but only those security roles that have been assigned to the app. However, through creting a team, a security group can be assigned security roles that aren’t allocated to a model-driven app, and the app can still be shared with that group.
With a Dataverse team, the team is positioned between the security group and the security roles, as shown below.
Step by Step
If not done so already, create your security group in the Microsoft Entra Admin Center, and add members to the group.
In the Power Platform Admin Center, select the Environment > Settings > Teams.
You will then see all the teams in the environment’s Dataverse table. This environment has only just been created so there is just a single team.
Clicking on create team at the top left of the screen allows us to create a new team. Complete the form and select ‘Microsoft Entra ID Security Group’ and add your security group. Click on next.
Add one or more security roles that you want to be assigned to the newly created team. Click save.
For this environment, all users who are members of the security group now have those security roles assigned to them, as long as they are members of the group. If they are removed from the group then those security roles privileges are rescinded.
An app can now be shared with the security group, without security roles needing to be assigned.
4) Assigning Security Roles to a User
It’s also possible to pre-assign security roles to users. This may be useful if the app only has one or two users.
Here the structure is the same as option 1. The only difference being that the user is pre-assigned security roles in the Power Platform Admin Center.
As with the other methods, additional security roles can still be added when an app is shared.
Step by Step
Ensure the user has been added to the default environment security group (if there is one assigned) and they have an appropriate license.
In the Power Platform Admin Center, select the Environment > Settings > Users
What we then see is a list of all the users with disabled and enabled status
Select ‘Manage security roles’ against a user
Now security roles can be added or removed
An app can now be shared with individual users, without further security roles needing to be assigned.
Additional Info
An app may have two distinct groups of users who access to different functionality or data. Assigning security groups delivers this model as multiple security groups can be created and have seperate security roles assigned. The app can then be shared with both groups.
If security roles have been assigned at the environment level, when sharing an app with a user or security group, these security roles are viewable but cannot be removed. Conversely, bear in mind that it is possible for the app sharer to assign additional security roles.
Anyone who has the privilege to share an app can also assign security roles. Any security roles assigned to a user or security group when an app is shared, can be removed in the Power Platform Admin Center.
Security role privileges are accumulative, and an individual user will have the cumulation of all the roles directly assigned to them, plus those assigned to security groups of which they are members.
As I mentioned earlier, it’s possible to prevent Makers from sharing apps altogether, and I’ll cover how to do this in the next post.