Introduction

Data drives every business and forms the core of all applications, flows, and power pages on the Power Platform. While the Power Platform can connect to many data sources, most Power Apps rely on Dataverse in some capacity, highlighting its crucial role in the ecosystem.

Data is the lynchpin of business, so securing it is critical. An organisation must control who has access to data and what they can do with the data. This ensures that end users can still do what they need to without the risk of data leaks.

One of Dataverse’s standout features is its robust security model, which can adapt to many business requirements and usage scenarios.

In this series, we will look at the different security settings in Dataverse. Hopefully, this will help give a better understanding of when and where to use the options provided for the next solution you develop.

Security Roles

Dataverse utilises what is known as role-based security. These ‘Security Roles’ are predefined, allowing those granted access to the data set by the role. Roles can be assigned directly to users, a security group or a business unit. This means that any user who has been included in the team or business unit automatically inherits the privileges of the assigned security role.

It is important to know that data access via roles works on accumulative privilege, meaning that the users with the most access prevail.

Creating Security Roles

Before creating a role, it is important to understand what your end users will want to achieve by using the data. This will help develop a robust security model, making sure that users can easily complete their tasks without the risk of data being shown to those who should not have access to it.

Role Privileges

Dataverse has a total of eight defined permissions with which to use to control data access at the table level, they are:

Create: This allows for the creation of records

Write: This will enable users to modify records already created

Read: Users with this privilege can view the information in an existing record.

Delete: Allows users to delete records.

Append: Users can create relationships with child-level records.

Append To: Allows records in a table to be related to parent-level tables.

Assign: Users have permission to reassign records to other users.

Share: Allows records to be shared with access teams.

Privilege access levels

The Dataverse platform allows for control over access via privileges and roles. Each table can be assigned unique privilege levels to ensure that only authorized users can access and/or manipulate the data.

A system administrator can use the menu to set the required access level for each table. By default, all custom tables are set to ‘none.’ Below are listed all the levels of access a privilege can be given, along with its description.

None
No access is allowed
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.
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.
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.
Organisation
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.
(Access Levels – Microsoft Learn)

Creating a Security Role

Security roles can be created in two main ways within the power platform; either through the power platform admin centre or in individual project solutions. I prefer to create security roles for projects within the solution of that project. This helps to keep me organised. As such, this short guide will focus on creating security roles in a solution.

Create a new security role

To begin, navigate to the project solution. Once in the solution, you can add an existing solution using ‘Add existing’, though in this example I will create a new role by clicking on ‘+ New’, going to the ‘Security’ menu and ‘Security Role’.

This will bring up a menu which allows you to give your new security role a name, you will then assign it to a business unit, and then select privilege inheritance, as shown in the image below I’ve left this in this example to ‘Direct User (Basic) access level and Team privilege’.

In terms of inheritance, there are two options either like I used in the above image ‘Direct User (Basic) access level and Team privilege’ or ‘Team privileges only’.

Team privileges only
The user is granted these privileges as a member of a team. Team members who don’t have user privileges of their own can create records with the team as the owner. They can access records that the team owns if they’re given the ‘User’ access level for Create and Read privileges.
Direct User (Basic) access level and Team privilege
The user is granted these privileges directly when the security role is assigned. Users can create records with themselves as the owner. They can access records that they created or owned when the ‘User’ access level for Create and Read privileges was given to them. This setting is the default for new security roles.
(Define the privileges and properties of a security role – Microsoft Learn)

Select custom table

The initial view you will be greeted with is all the tables which are associated with the security role, if you are trying to give access to a custom table, select ‘Show all tables’ in the dropdown, then either scroll to the Custom Tables section and look for your table, or you can search for the table name in the search box top right.

As shown in the picture above I have selected the levels of access for my custom table, once you have completed this then click save. If you don’t require a high level of customisation on your tables, there is also the option of picking a selected of predefined permission settings, to do so select the table, by clicking the radio button, then in the ribbon click ‘permission settings’ and choose the one which best suits your needs.

Additional permissions

In addition to the table permissions, there are also ‘Miscellaneous privileges’ and ‘Privacy-related permissions’ which will allow your security role additional permissions. Though these are outside the scope of this initial intro post.

Conclusion

In conclusion, securing data within Dataverse is an essential aspect of leveraging the Power Platform effectively. By understanding and implementing the robust security model provided, organizations can ensure that their data is protected while still enabling users to perform their necessary tasks efficiently. The role-based security system, with its various privilege levels and customizable security roles, offers a flexible and comprehensive approach to data security. As you develop your next solution, consider the security requirements carefully and utilize the options available in Dataverse to create a secure and efficient environment. This series aims to provide you with the insights and knowledge needed to make informed decisions about data security in your Power Platform projects.

Given the importance of securing data within Dataverse, how do you approach designing security roles and privilege levels to balance both accessibility for end users and the protection of sensitive information in your Power Platform projects?