Dataverse Security Roles

Security roles are the access foundation for Power Platform users. If you want to build in an environment, you need the 'Environment Maker' role, want to be environment admin, you need the 'Environment Administrator' role, and so on.

But what you might not realise is these security roles are the exact same as when you create your own Dataverse tables. The only difference is some of the roles have added claims (permissions that are beyond Dataverse access), the rest are just permissions to tables.

With the move to solutions the Power Platform has moved its internal data to Dataverse, that's right the platform is now built on itself. What does that mean, well if you want to create a flow you need permissions to the Workflow table, want to create an environment variable, permissions for Environment Variable Definition and Environment Variable Value tables.

So just like you give a security role that has permissions for the workflows table to create a flow, we create a security role with permissions to your custom table, else no one (including you even if you created it) can create/read/update/delete records in the table.

So lets dive in:

1. Prerequisites


2. How to Create a Role


3. Role Permissions


4. ALM (Migrating between environments)

1. Prerequisites

As I have said, security roles for Dataverse tables are the same as the security roles for using the platform, so we have a problem. That means if you can create security roles for tables, you can create roles for the platform. If there was an earned permission setup (so you can only set permissions you own) then we might be able to split, but that's not how it is. If you can make/edit security roles, you can give someone (yourself included) the System Administrator role. So with that in mind, the only role that can create/edit security roles, is the System Administrator role. I know what you are thinking, creating roles is not a problem, allocating members to the role is the issue (You can create Dataverse tables, just not add data, why can't roles be the same). I don't know why, but I suspect from a security side it would be dangerous, as these additional permissions could be added without permission.

Not ideal from a self service approach, but that is how it is, you need a custom role, you need a System Administrator to do it for you.

2. How to Create a Role

There are 2 ways to create a role, PPAC (Power Platform Admin Centre) or from a solution (yep they are solution aware).

In the PPAC select the environment you want to create the role (should be a dev environment, as Blocked Customizations stops new/edit roles, so they need to be imported). Select Security Roles from the Access card and then either select the role to edit/duplicate, or click New Role.

Name the role, set the business group to apply to (for everyone select the default/root environment group). The group selected relates to any permissions set to Business Units (see later). You can also give the role member the ability to use Model Driven Apps.

You can also set Member's privilege inheritance, as either Team, or Team and User. Team means you can only have team permissions (teams owned records etc), and you have no permissions as a user (user owned records etc). So far I have personally never used just teams, but its there if you need it.

), you have more if you give permission to use Model Driven Apps, just leave them as they cause no harm.

But there is a small problem 354 of them. How have I created 354 custom tables, well I haven't, Microsoft has (well most, I do have a few). Every new update to the Platform uses custom tables. Even tables you really think are core/system are custom as they were created later.

1. None

No access (default)

2. User

Lowest level with access, this is only for records you own (created by you or assigned to you).

3. Business Unit

Only records that are owned by the business unit set to this role, remember (see later) earlier in the blog, this is later.

4. Parent: Child Business Units

Records own by child business units (setup in hierarchy, that and Business Units a blog for another day).

5. Organization

All records.

There is a dropdown for each permission allowing you to select the access level.

The Permission Settings field is updated when saved, and will show one of the following:

• Reference: Org Read Only


• Full Access: Org for all


• No Access: All None


• Collaborate (Parent/Business Unit): BU/Parent for all


• Custom: Every other combination

4. ALM (Migrating between environments)

Think I mentioned already that Security Roles are solution aware, guess what, they are stored in a Dataverse table called roles. Though this is meta data, and does not hold the actual permissions. When you add your security role to your solution you see a component type Security Role added.

If you don't select the environment root business unit for the role it will fail when you try and add it to a solution. But here's the flip, you set the Business Unit on each team, so when you give a team the role, it automatically switches to that Business Unit. So I struggle to understand why you set the Business Unit to the role when you create it, maybe for individual users, but why create a role for a Business Unit when you could create a team for each 🤷‍♂️. Smarter people the me please explain in the comments (and other mistakes I have made in this blog).