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.

In a solution click New, Security Role (you can also add existing roles to the solution).

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.

3. Role Permissions

Now the role is created we need to give it permissions (else its a pretty useless role). The role will have multiple default permissions already set (MSLearn-minimum-privileges-for-common-tasks), you have more if you give permission to use Model Driven Apps, just leave them as they cause no harm.

You can see a drop down that lets you select 'Show Assigned Tables' (ones you have permissions), 'Show Unassigned Tables' (yep you guessed it, tables with no permissions), and 'Show All Tables (....).

There are 3 types of permissions:

Miscellaneous Permissions

None record permissions, from what I can gather these are API based permissions, example run flows (this allows you to trigger, like from a Power App).

Privacy-related Permissions

Same as Miscellaneous Permissions but with higher risk due to impact on data/privacy e.g. Export to Excel

Tables

The big one, and for Dataverse tables the only one you really care about, this gives permission to table records.

The tables are grouped into sections, the one we really care about is Custom Tables.

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.

So you need to use the search input in the top right corner to filter the results to find your custom table.

Once you have your table you have the following permissions to give to the role:

• Create - create records
• Read - read records
• Write - update records
• Delete - take a guess 😉
• Append - use lookup columns
• Append to - use table when a lookup in another table
• Assign - be able to change owner
• Share - be able to share access

And for each of the permissions you have 5 levels of access:

1. None
2. User
3. Business Unit
4. Parent: Child Business Units
5. Organization

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.

The role can now be moved with your Dataverse tables from dev to test to prod. But you may spot the problem, Environment Makers do not have permission to create roles, and importing solutions creates roles.

So you need to split out your roles from any component owned by a maker (Flow/Canvas App/etc) so that a System Administrator can import the solution.

But there are more problems, Business Units are not solution aware, you cant deploy across environments (though I believe there is a work around to export to Excel and import). So if you can't include Business Units, how does a Security set to a Business Unit migrate, well it doesn't.

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).