UPDATED April 3rd.

Morten Zohnesen (LinkedIn Link) Provided some great feedback to my post.

Quick summary of changes My post is focused solely on personal ownership of records. If you are using team ownership of the records, the “user” ownership applies to the entire team then instead. It’s possible to also set user privileges to entire tables to “Organization” and furthermore you can set user privileges in security roles so that only Team privileges apply. I will probably have to make an entire post about this. So, this post is only focused on working with tables and security roles where user ownership is in use.

Furthermore, Morten noted that I should update the wording on the cascading aspects of ownership in table relationships. Previously I used the word “Sharing” to indicate that records were shared, but in fact the ownership is changed to the owner of the parent record, similar to the “Assign” operation.

Original post:

In this post I want to talk about some of the many aspects of security roles and how they work. It’s something I often get asked about and worth spending some time on.

Put shortly, when working with security roles, you want to either limit, expand, or simply understand the basic question:

Who can do What

In Microsoft terminology we use the following terms to describe this:

Defining Who is done via the Access Level
And
Defining What is done via the Privilege Type

I’m going to split this post up into different two different sections from the picture below, the first is the different Access Levels that are selected from the dropdown – User, Organization, etc. – and second is the different Privilege Types as seen in the columns – Create, Read, Write, etc. – but first we also need to go through some basics of how security roles function in the realm of the Power Platform.

Basics of Security Roles

Owning user When working with security roles and managing access based on the tables, the most important field to be aware of is the “owner” field. As this will affects everything discussed here. Records need to be owned by a user, and either the user, or the relationship(relationship as in, being part of the same business unit, organization, etc.) a user has to the owning user is key to how we want to set up our security roles.

Relationships Furthermore, when creating relationships between tables, you can select how the relationship affects records from the parent to the child table. If you select “Parental” as the relationship type, then all records on the child table will get the same type of ownership as the parent record (cascading), when the two records are linked. If you want to avoid this, you can also select “Custom” relationship and define the cascading nature of each element as seen in the image below.

Access levels

User

This access level restricts the access to the table records to only the include records that have the user assigned as owner (or those that are shared with the user). For example, when selecting the “User” Access level under the “Read” Privilege type, the user is only able to read records from the table that the user either Owns or that have been shared with the user.

Business Unit

All users in the business unit of the owner have access to the record. The same is true of records shared with the business unit directly (the business unit can be selected in the same way as a user or a team). The Business unit can also be the owner of the records given that the business unit has the correct permissions for this.

Parent: Child Business Unit

Users can access any record in their own business unit and also the records of all child business units. Seeing as business units can be set up hierarchically this means that all business units below the user’s business units are considered “child” business units.

Organization

All users within the organization, irregardless of business units, have access to the record to perform the given privilege in question.

Privilege types

Create

The ability to create records on any table. The significance of this being either “User”, “Business Unit” or “Organization” only has any meaning when working with a combination of Tables that use either the User or Team setting. When working with “Organization” ownership. We no longer use the User or Business unit settings as they do not apply the same way.

Read

This setting is valid for any type of table. The ability to read records based on the permissions you have for the table. For User you can only see records that are assigned directly to you or have been shared with you using the “Assign” function.

If you only have the “User” permission for a table, any records in a table that is not assigned or shared with you will not show up in any view and be inaccessible even with a direct link to the record.

Write

Same as with read, this controls the ability to make changes to any field on the record itself.

For example:

A user could have read permissions on the “Organization” level for a table, but only be able to write to some of them because the user was only given *User access to the Write Privilege

Delete

This defines the ability of a user to delete record within the table. Keep in mind that if a user has the ability to Delete records with organization as the Access Level, but only has Business Unit as the Access level for the Read Privilege. The user will not be able to delete record outside of their business unit via the Power App. However, it makes sense to keep the access levels at a similar level to avoid confusion. Generally providing the Delete Access Level is something that should be kept to as few users as possible and deactivating records will in most cases be adequate.

Append

This allows the user to append or associate a record with another record. An example of this could be that I have a table of all the boat trips I go on. For each boat trip I maintain a log of the cities I have visited along the trip. I want to store the information about each city visited on each trip in a separate table. I therefore create a second table called City. In order to append the record of each city visited for each trip. I need to have Append rights to the City table.

Append To

This allows the user to append or associate records from other tables to the table in question.

Continuing from my previous examples. The user needs to be provided with Append To access to the Boat Trip table in order to complete the Append and Append to operation between the Boat Trip table and the City table.

Assign

This gives the user the ability to assign records from the table to other users, provided that the other user also has read rights to the table in question.

Share

This gives the user the ability to share the record in question with another user. It also requires that the user is able to Read records on the table in question.

Unlike the Assign Privilege Type, simply sharing a record does not change the ownership of the record. It merely adds the user. When sharing it’s possible to restrict the users Access Levels directly. The sharing cannot override the users own access levels, and can only provide access up to the limits posed in their own security role.

For example:

Aser A has “User” access to the read, Write, Delete and Share privileges to records on the Boat Trip table. User B has “User” access to the Read and Write privileges. But not Delete If user A shares a record with User B. Then it will not be possible to assign the Delete access level to the user, even if user A specifically selects this option while sharing.