Understand security concepts in Dataverse

Completed

One of the key features of Dataverse is its rich security model that can adapt to many business usage scenarios. This security model is only in play when there's a Dataverse database in the environment. As an administrator, you likely won't be building the entire security model yourself, but you'll often be involved in the process of managing users and making sure they have the proper configuration and troubleshooting security access related issues.

Role-based security

Dataverse uses role-based security to group together a collection of privileges. These security roles can be associated directly to users, or they can be associated with Dataverse teams and business units. Users can then be associated with the team, and therefore all users associated with the team will benefit from the role. A key concept of Dataverse security to understand is that privileges are accumulative with the greatest amount of access prevailing. For example, if a user has two security roles, one with delete privileges but without write privileges, and the other with write privileges but without delete privileges, the user will be able to both delete and write in the environment. Likewise, if you gave broad organization level read access to all contact records, you can’t go back and hide a single record.

Business units

Business Units provide security and structure for grouping users and are often used to mimic an organization’s departmental structure. Every user assigned to a Dataverse environment will belong to a business unit. Every Dataverse database has a single root business unit, and multiple child business units can be created as needed. Child business units can be deleted, however, the root business unit can’t be deleted. Also, child business units can have other child business units.

  • A parent business unit is any business unit with one or more business units that report to it in the hierarchy.

  • A child business unit is a business unit that is immediately under another business unit in the business hierarchy of an organization.

Business units can be structured in accordance with a traditional organizational structure for hierarchical data access, or they can structure business units so that data is compartmentalized in a tree-like hierarchy, and user can work and access any business unit's data regardless of what the business unit the user is assigned to. For more information on how to achieve a data structure like this, see Matrix data access structure (Modernized Business Units).

Note

A user’s security roles are assigned within their business unit. If a user is moved to a different business unit, their security roles must be re-assigned. Each user is a member of only one business unit, but a team can have user members from multiple business units. Implementing column-level security will be described later in this module.

Table/record ownership

Dataverse supports two types of record ownership. Organization owned, and User or Team owned. Record ownership is a choice that happens at the time the table is created and can’t be changed. For security purposes, for records that are organization owned, the only access level choices is either the user can do the operation or can’t. For user and team owned records, the access level choices for most privileges are:

  • Tiered Organization

  • Business Unit

  • Business Unit and Child Business Unit

  • or only the user’s own records.

Record ownership in Modernized Business Units

In Modernized Business Units, you can have users being owners of records across any business units. All the users need is a security role (any business unit) which has Read privilege to the record table. The users don't need to have a security role assigned in each business unit where the record resides. Using this capability requires some adjustments to your Organization Settings. You can learn more how to set up in Record Ownership in Modernized Business Units.

Teams (including group teams)

Teams are another important security building block. Teams are owned by a Business Unit. Every Business Unit has one default team that is automatically created when the Business Unit is created. The default team members are managed by Dataverse and always contain all users associated with that Business Unit. You can’t manually add or remove members from the default team, they're dynamically adjusted by the system as new users are associated/disassociated with business units. There are two types of teams, owning teams and access teams.

  • Owning Teams can own records, which give any team member direct access to that record. Users can be members of multiple teams. This will allow it to be a powerful way of granting permissions to users in a broad way without micromanaging access at the individual user level.
  • Access teams are discussed in the next section as part of record sharing.

Record sharing

Individual records can be shared on a one by one basis with another user. This is a powerful way of handling exceptions that don’t fall into the record ownership or member of a business unit access model. It should be an exception though because it's a less performant way of controlling access. Sharing is tougher to troubleshoot because it's not a consistently implemented access control. Sharing can be done at both the user and team level. Sharing with a team is a more efficient way of sharing. A more advanced concept of sharing is with Access Teams, which provides auto creation of a team and sharing of record access with the team based on an Access Team Template (template of permissions) which is applied. Access teams can also be used without the templates, with manual add/remove of its members. Access teams are more performant because they don’t allow owning records by the team or having security roles assigned to the team. Users get access because the record is shared with the team and the user is a member.

Record-level security in Dataverse

A user's access to a record is the combination of all their security roles, the business unit they're associated with, the teams they're members of and the records that are shared with them. Remember that all access in Dataverse is accumulative across all of those concepts in the scope of a Dataverse database environment. These entitlements are only granted within a single database and are individually tracked in each Dataverse database, requiring a user to have an appropriate license to access Dataverse.

Column-level security to control access

When record-level control isn't adequate for your business scenario, Dataverse provides a column-level security feature to allow more granular control of security at the column level. Column-level security can be enabled on all custom columns and most system columns. Each column’s metadata defines if that is an available option for the system column.

Column-level security is enabled on a column by column basis. Access is then managed by creating a Column Security Profile. The profile contains all columns that have column-level security enabled and the access granted by that specific profile. Each column can be controlled within the profile for Create, Update and Read access. Column Security Profiles are then associated with a user or Teams to grant those privileges to the users to the records they already have access to. It’s important to note that column-level security has nothing to do with record-level security. A user must already have access to the record for the Column Security Profile to grant them any access to the columns. Column-level security should be used as needed and not excessively as it can add overhead that is detrimental if over used.

To learn more on implementing column security, we've included an example a bit further below in this unit.

Managing security across multiple environments

It's possible to package up and move Security roles and Column Security Profiles from one environment to the next using Dataverse solutions. Business Units and Teams must be created and managed in each environment along with the assignment of users to the necessary security components.

Configuring users environment security

Once roles, teams, and business units are created in an environment, you can assign the users their security configurations. First, when you create a user, you'll associate the user with a business unit. By default, this is the root business unit in the organization. They're also added to the default team of that business unit.

In addition, you would assign any security roles that user needs. You would also add them as members of any teams. Remember teams can also have security roles, so the effective rights of the user is the combination of directly assigned security roles combined with those of any teams they're members of. Security is always additive offering the least restrictive permission of any of their entitlements.

Also remember, if you have used column-level security, you would need to associate the user or a team of the user to one of the Column Securities Profiles you created.

Because of its complexity, establishing a security plan is best accomplished as a joint effort between the application makers and the team administering the user's permissions. Any major changes should be coordinated well in advance of deploying the changes into the environment.

How to configure column security example

Before we begin our example let's discuss how to implement column-level security. A system administrator will need to perform the following tasks:

  1. Enable column security on one or more columns for a given table.

  2. Associate one more existing security profile or create one or more new security profiles to grant the appropriate access to specific users or teams.

    A security profile determines:

    • Permissions to the secure columns

    • Users and Teams

    A security profile can be configured to grant user or team members the following permissions at the column level:

    • Read. Read-only access to the column's data.

    • Create. Users or teams in this profile can add data to this column when creating a record.

    • Update. Users or teams in this profile can update the column's data after it has been created.

    A combination of these three permissions can be configured to determine the user privileges for a specific data column.

    Important

    Unless one or more security profiles are assigned to a security enabled field, only users with the system administrator security role will have access to the field.

Now, here's the background for our example: Your company's policy is that only account managers and system administrators should be able to view a customer's credit limit.

To restrict access, you can implement column level security by completing the steps below:

Enable column security

  1. Sign in to Power Apps as an administrator.

  2. Select an environment.

  3. On the left pane, select Dataverse.

  4. Select Tables, then select the All view.

  5. Select the Account table.

  6. In Schema pane, select Columns. Find and select the Credit Limit column (you can use the search entry field at the top right of the Columns view or scroll down the list).

  7. On the right pane, select Advanced options.

  8. Select Enable column security.

  9. Select Save. Once saving is complete, column security is enabled.

Configure the security profile

  1. Sign in to Power Apps as an administrator.

  2. On the top right, select the gear (Settings) icon and select Admin center. This opens up a separate Power Platform admin center browser instance.

  3. Select Environments from the left-side navigation menu, and select the environment where you would like to set up the security profile.

  4. From the header ribbon, select Settings.

  5. Select the dropdown next to Users + permissions, and select Column security profiles (alternatively, you can search for this setting in the search field under the Settings screen header).

  6. At the top ribbon, select + New Profile and a pane will appear on the right side of your screen called Create new column security profile. Enter a name such as Account Manager, you can also add a description if you like.

  7. Select Save and the pane will close to reveal your new profile listed under Column Security Profiles.

  8. Select your Account Manager profile. Next we'll add some users to this profile. There are three tabs depicted under the screen header including Column Permission (where you are by default), Teams and Users. Select the Users tab.

    Screenshot of the Account Manager security profile screen with the Users tab highlighted.

  9. Select + Click here to Add Users, and an Add Users pane opens on the right side of the screen. Enter the user names or email addresses for the users to wish to add, and then select the name from the dropdown that appears and they're added to the list. If you add a name by mistake, you can select the X to the right of the user to remove them from the list.

  10. Once you're satisfied with your list of users, select Add at the bottom of the Add Users pane. If you need to add other users, notice the + Add Users button at the top of the screen.

  11. Now select the Column Permission tab.

  12. Select the Credit Limit column, and on the top select Edit.

  13. In the right side Edit column security pane, under Read, select Allowed.

  14. Select Save, the pane will close, and your Column Permission tab displays the new settings for Account Managers for the Credit Limit column.

What this means is that any users not in the Account Manager profile for this column won't have access to the credit limit column in the Account table or views. The field value displays a Lock icon with ********, indicating the field is secured.

Hierarchy security to control access

The hierarchy security model extends Dataverse security by allowing managers to access the records of their subordinates or do work on their behalf. It can be used with all other existing security models.

Two security models can be used for hierarchies, the Manager hierarchy and the Position hierarchy. With the Manager hierarchy, a manager must be within the same business unit as the subordinate, or in the parent business unit of the subordinate’s business unit, to have access to the subordinate’s data. The Position hierarchy allows data access across business units.

Manager hierarchy

The Manager hierarchy security model is based on the management chain or direct reporting structure. The manager’s and the subordinate’s relationship is established by using the Manager field on the user table. With this security model, the managers are able to access the data that their subordinates have access to. They're able to perform work on behalf of their direct reports or access information that needs approval. The manager can have full access to the subordinate’s data for their direct reports. For nondirect reports, a manager can only have the read-only access to their data.

Position hierarchy

With the position hierarchy security, various job positions in the organization can be defined and arranged in the hierarchy using the Position table. You can then add users to any given position using the Position lookup column on the user record. Users at the higher positions in the hierarchy have access to the data of the users at the lower positions, in the direct ancestor path. Similar to manager hierarchy, the parent positions have full access to the child positions’ data but the positions higher than a direct parent have read-only access.

Note

In both hierarchy models, a user higher in the hierarchy must have at least the user level Read privilege on a table, to see the subordinates’ data. For example, if a manager doesn’t have the Read access to the Case entity, the manager won’t be able to see the cases that their subordinates have access to.

How to configure Hierarchy Security example

Let's walk through how to set up hierarchy security in an environment in your organization. First, we'll configure the settings then we'll set up manager and position hierarchies.

Configure hierarchy security system settings

Make sure you have the System Administrator permissions to update the settings. If you don't have the correct permissions, you'll need to contact your system administrator.

The hierarchy security is disabled by default. To enable:

  1. Sign in to Power Apps (as an administrator).

  2. On the top right, select the settings gear icon and select Admin center.

  3. Select Environments from the left side menu, and select the environment you wish to configure.

  4. From the top ribbon, select Settings.

    Screenshot of the settings with security selected under systems.

  5. Select the Users + permissions drop down then select Hierarchy security.

    Screenshot of security with hierarchy security selected.

  6. After a few moments, a new browser tab titled Hierarchy Security will open. Select the check box next to Enable Hierarchy Modeling and the Hierarchy Model options will be available. In this case, let's ensure that Manager Hierarchy is selected and that your Hierarchy Depth is set as 3 (these are default values). The hierarchy depth is how many levels deep a manager has a Read-only access to the data of their reports.

    Important

    To make any changes in Hierarchy security, you must have the Change Hierarchy Security Settings privilege.

    Screenshot of the hierarchy modeling enabled, model selected, and depth set.

Set up Manager and Position hierarchies

We can create a Manager hierarchy by using the manager relationship on the system user record. You use the Manager (ParentsystemuserID) lookup field to specify the manager of the user. If you've already created the Position hierarchy, you can also tag the user with a particular position in the Position hierarchy.

In your Hierarchy Security browser tab where you've turned on Enable Hierarchy Modeling and enabled Manager Hierarchy, do the following:

  1. Under Manager Hierarchy, select Configure.

  2. Assign each user a manager and position (Optional). You can search for a user by using the filter field in the upper right. Select a user from under Enabled Users to bring up the User pop up window.

Screenshot of the enabled users window.

In the following example, we've selected our user Adele Vance. Adele Vance reports to Nestor Wilke in the Manager hierarchy and also has the Sales Person position in the Position hierarchy:

Screenshot of Adele Vance's user window.

To add a user to a particular position in the Position hierarchy, select the lookup field called Position on the user record’s form. Existing positions in your organizational hierarchy will show, and you can search for positions by using the search field.

Screenshot of the positions field with sales person selected.

You can add positions as required, by selecting + New Position, which will bring up a New Position pop up window. Then you enter in the Name and (optionally) the Parent Position. If you save this position, it will be available in your position hierarchy.

Screenshot of the New Position window.

To create a position hierarchy

  1. Sign in to the Power Platform admin center.

  2. Select Environments and choose your environment to modify.

  3. Select Settings from the ribbon.

    Screenshot of security selected under system on the settings screen.

  4. Expand Users + permissions and select Hierarchy security (alternatively you can enter hierarchy in the Search for a setting field under the header).

    Screenshot of the hierarchy security highlighted on the security window.

  5. Select Enable Hierarchy Modeling then, for positional hierarchy, select the radio button next to Custom Position Hierarchy, and ensure the Hierarchy Depth is set to 3.

    Screenshot of the hierarchy modeling enabled, position hierarchy set to custom, and the depth set to three.

  6. Under Custom Position Hierarchy, select Configure.

  7. For each position, provide the name of the position, the parent of the position, and the description. Add users to this position by using the lookup field called Users in this position. Below is an example of Position hierarchy with the active positions. You can select any of the positions and assign/add other positions in your hierarchy.

    Screenshot of the active positions.

  8. If you select a position, you can see a list of users in this position. Each user is selectable. Selecting a user navigates you to their User admin screen where you can change user details as required. Back arrows at the top left of the window will navigate you back to previous screens.

    Screenshot of the Sales Person screen showing Adele Vance in the Users in this position.

  9. You can use the Active Positions screen to ensure each user is set up with the correct positions in your hierarchy.

Performance considerations

To boost the performance, we recommend:

  • Keep the effective hierarchy security to 50 users or less under a manager/position. Your hierarchy might have more than 50 users under a manager/position, but you can use the Depth setting to reduce the number of levels for Read-only access and with this limit the effective number of users under a manager/position to 50 users or less.

  • Use hierarchy security models with other existing security models for more complex scenarios. Avoid creating a large number of business units, instead, create fewer business units and add hierarchy security.