A few years ago, I’ve shifted my attention from Project Online towards the modern “Model Driven Power Apps” solutions. And with this switch there’s a lot of new information to learn. One of the most steep learning curve was/is regarding the permissions structure of Model driven Power Apps.
This article is as much here to help you along the way when you are pressed to work with security topics in model driven power apps. As it is a reminder for myself on “how did that work again?”.
This is a more technical article than you might be used to on The Project Corner, and I can fully understand if this is not something to your taste. Please, take some time to explore the other articles on the site.
Note: for readability purposes, I might at times omit the “Model Driven” part when I mention Power Apps. However, this article does not cover anything related to Canvas apps or Pages in any way, intentionally at least.
Modern views
In this article, I’ll only work with the Modern interface for permissions, which was introduced somewhere around 2023-2024. However, it is good to note that we previously had a different interface that had a circle represent the level of access for a role.
As you can see, the classic interface is more compact, but also less descriptive with the “access levels” on the “privileges”.
At this moment, it’s also good to note that Power Apps are build on top of Dataverse. And in case Dataverse is a new term for you, here’s a part of the definition Microsoft gives us:
Data within Dataverse is stored within a set of tables. A table is a set of rows (formerly referred to as records) and columns (formerly referred to as fields/attributes).
Let’s take a look at the official documentation regarding the access levels and privileges before we move on:
| Type | Description |
|---|---|
| Organization | Users can access all records in the organization, regardless of the business unit hierarchical level they or the environment belong to. Users with organization access automatically have all other types of access as well. Because this level gives access to information throughout the organization, it should be restricted to match the organization’s data security plan. This level of access is usually reserved for managers with authority over the organization. |
| Parent: Child Business Unit | Users can access records in their business unit and all business units subordinate to it. Users with this access automatically have business unit and user access. Because this level gives access to information throughout the business unit and subordinate business units, it should be restricted to match the organization’s data security plan. This level of access is usually reserved for managers with authority over the business units. |
| Business Unit | Users can access records in their business unit. Users with business unit access automatically have user access. Because this access level gives access to information throughout the business unit, it should be restricted to match the organization’s data security plan. This level of access is usually reserved for managers with authority over the business unit. |
| User | Users can access records they own, objects that are shared with the organization, objects that are shared with them, and objects that are shared with a team that they’re a member of. This is the typical level of access for sales and service representatives. |
| None | No access is allowed. |
And for the privileges we have this table, with descriptions on what each privilege means.
| Privilege | Description |
|---|---|
| Create | Required to make a new record |
| Read | Required to open a record to view the contents |
| Write | Required to make changes to a record |
| Delete | Required to permanently remove a record |
| Append | Required to associate the current record with another record; for example, if users have Append rights on a note, they can attach the note to an opportunity In the case of many-to-many relationships, a user must have Append privilege for both tables being associated or disassociated. |
| Append to | Required to associate a record with the current record; for example, if users have Append To rights on an opportunity, they can add a note to the opportunity |
| Assign | Required to give ownership of a record to another user |
| Share | Required to give access to a record to another user while keeping your own access |
Reading these tables gives a good overview of what a person can do inside a model-driven app. Here is an example image of a person that can create, read and write risks, but only his/her own records:
Business units
Business units help you silo your environment. Giving you an extra level of security, visibility, and usability, of records between everything (organization) and only things you own (user).
In the PM context I always like to envision this in a small WBS:
Enterprise PMO
-Department x projects
-Department y projects
-Department z projects
– -Subdepartment z 1 projects
– – Subdepartment z 2 projects
There are 2 privileges specifically related to the business units: parent-child business unit and business units.
In our example above, the Parent: Child Business Unit privilege will provide a “Department Z” User access to all projects within Department Z, and Z1, and Z2.
Where a person with only the “Business Unit” level for Department Z would only see the projects associated with Department Z.
I always build security roles to associate with Entra ID Security groups (Former Azure AD groups). But the Business Units need to be attached to a user of the system. And, be mindful, a person can only belong to 1 business unit!
There is always a top level Business unit (this is the organization). Below you can go crazy and design a whole structure for more units to mimic your org, or the regional silo’s for your app.
The business Units give us the ability to create a German PM and a Dutch PM. Where the German PM is only allowed to see his/her own projects, and the Dutch PM is allowed to see all the Dutch projects Including the one’s in the child units. This is how the read privilege would look for both:
Append, and Append to
This specific section of security always bugs me. The main reason for this is that the security relates to the permissions related to two tables.
Let’s take another look at what the official documentation states:
| Append | Required to associate the current record with another record; for example, if users have Append rights on a note, they can attach the note to an opportunity In the case of many-to-many relationships, a user must have Append privilege for both tables being associated or disassociated. |
| Append to | Required to associate a record with the current record; for example, if users have Append To rights on an opportunity, they can add a note to the opportunity |
For the first Privilege, we could formulate it so: “Append with something”. The second privilege could then be formulated so: “Append to me”.
With this in mind, we can take another example from the PMO world. Let’s discuss attaching Risks to Projects:
There are two tables involved, Project and Risk.
On the Project table, we should set the permissions so that anyone in the business unit can attach a risk to the project. Which comes down to setting the Project Table Append To (the project) privilege to Business Unit. On the Append, we could do the same, but that would then relate to Append the project to a program or portfolio for instance (Append … Project … with something).
On the Risk table, we should set the permissions so that anyone in the business unit can append (with) the projects. That means we will set the Risk Table Append privilege to Business Unit as well.
What does it mean if I set only the Project Append To privilege to User?
In that case, a user with that security role, Append To (me) will only allow the user to append other records to records he/she owns. Setting this privilege on the Projects makes sense, because you don’t want another PM to add risks “or other stuff” to the projects you own.
“Never” provide security roles directly to users
Once you porvided security roles for your app, you need to make sure people are “boxed in” with the right security settings.
It’s possible to give a security role to a single user, but this is by no means a best practise. It will become very labour intensive to monitor and alter all those people’s roles. So, instead of working with access from the Power Platform side, it’s much wiser to provide access through the application that’s designed for it:
Entra ID
By creating the different Entra ID Security groups, we can administer access in one central location.
When creating the Entra ID groups, similar Power Apps security Teams need to be created as well. And as a final step, you would assign the security roles to the teams in Power Apps.
Yeah, group teams … not the best naming convention.
Locking an environment to a security group
In Tatu’s presentation (source at the end of the article), he mentioned the need to have an additional security setting. One that will lock all users out of the environment, unless they are a part of a specific Entra ID Security Group.
This is a optional setting, but if you are working with very secure data, it is also an additional layer of security.
The request to add a security role to the environment is shared as part of the creation steps, but can also be done after the environment is created. Make sure your admin user is a part of this group because they will also be kicked out if they are not.
Column-Level Security
We covered App-level security, we covered record-level security. Now let’s dig into field or, officially “Column”-level security, because we can zoom in on that level as well, but it’s a bit different from the other levels. First, it needs to be set for individual fields/columns in the solution. When selecting the column security, you get the chance to state what type of security mask to add. This can be usefull if you work with very sencitive data such as social security numbers etc. For me, I typically keep the default: “none”.
Second, you need a column security profile, and I always create at least two: one to edit, and one that isn’t allowed to edit or isn’t allowed to see the content.
Next
In the Column security profile, all fields that have the column security setting checked show up. With 3 levels of access: Read, Update and Create. You can edit each fields level of security via the edit button on the top:
Notice the two other sections on the top left as well:
By now I think it won’t come as a surprise that you should lock in the security profile on Teams and not on individual users 😉.
Power Automate Approvals
For this little section I’ve been hunting for examples, but couldn’t find any. That’s why I took the lazy route and let ChatGPT help me out with the description.
Approvals will not work without the “Approvals User” and “Approvals Administrator” roles.
Approvals User Role
The Approvals User role is a security role within Model-driven Power Apps. It is essential for managing approval processes within the app. So what does this role do?
- Review and approve data and documents: Users can review, approve, or reject submissions.
- Access approval workflows: Users interact with workflows, often automated via Power Automate.
- Record-level privileges: Users can read, create, and update records needing approval.
- Task-based privileges: Users can perform specific actions like publishing articles.
Approvals Administrator Role
The Approvals Administrator role is a service-level role that applies to the Power Automate Approvals system. It is not a Dataverse security role, but rather a Microsoft 365 / Power Platform admin role that provides centralized visibility and control over approval requests and configurations across environments. So what does this role do?
- View and manage all approval requests: Users can view and manage all approval requests in an environment, regardless of who created them.
- Cancel, reassign, or retry stuck or failed approvals: Users can handle stuck or failed approvals.
- Access the Approvals Center: Users can access the Approvals Center in Power Automate admin.
- Support, auditing, and governance: This role is useful for support, auditing, and governance.
Both roles are crucial for ensuring efficient, accountable, and secure approval workflows within your projects.
Final notes
Some final best practices to send you on your way:
- Regularly audit user permissions (or have the Entra ID team do this) to ensure that only authorized users have access to sensitive data and functionalities.
- Granting excessive permissions to users can lead to security vulnerabilities. Ensure users only have the permissions necessary for their roles.
- Don’t forget to monitor the audit logs: Not monitoring audit logs can result in missed opportunities to detect and respond to security incidents.
- And don’t forget to implement proper back up and restore options just in case things go south. Projectum has a solution for this that might be of interest: Power Hub
- Make sure you DOCUMENT, the security settings you create/change.
I hope you enjoyed reading this article on Model driven Power apps permissions explained. And because it’s such a big topic, you might also like to read the sources I’ve used in this article. And, I might return to this article if security needs additional content.
Sources that helped me write this article:
- Securing the app and data (MSFT Learn)
- Security roles and privileges (MSFT Learn)
- Enable Column (field) security (MSFT Learn)
- Presentation slidedeck “Streamlining Power Platform access and security role management with Entra ID” (Fellow TDN MVP Tatu)
- Deep-Dive in Power Platform Security Roles – Power Apps Viking (Fellow Projectum MVP Søren Weber)
If you’d like to get more, you could also subscribe to my newsletter or even book a meeting for a 1 on 1 to discuss a topic in detail.