Security roles and privileges
To control who can access restricted or sensitive data and resources and what they can do with them, assign users to security roles. This article provides an overview of security roles and their associated privileges.
You can assign security roles using the new, modern UI or the legacy UI.
Security roles and the new, modern UI
Security roles define how different users access different types of records. To control access to data and resources, you can create or modify security roles and change the security roles that are assigned to your users.
A user can have multiple security roles. Security role privileges are cumulative. Users are granted the privileges that are available in each role that's assigned to them.
View a list of security roles in an environment
Sign in to the Power Platform admin center, select Environments in the navigation pane, and then select an environment.
Select Settings > Users + Permissions > Security roles.
Define the privileges and properties of a security role
After you've created a security role or while you're editing one, set the Member's privilege inheritance option:
Team privileges only: A 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 privileges: A 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.
Then, configure the privileges associated with the security role.
A security role consists of record-level privileges and task-based privileges of the following three types:
Tables: Table privileges define which tasks a user with access to a table record can do, such as Read, Create, Delete, Write, Assign, Share, Append, and Append To. Append means to attach another record, such as an activity or note, to a record. Append to means to be attached to a record. Set table privileges.
Miscellaneous privileges: These task-based privileges give a user permission to perform specific, miscellaneous (non-record) tasks, such as publish articles or activate business rules. Learn more about miscellaneous privileges.
Privacy-related privileges: These privileges give a user permission to perform tasks that involve data that's integrated, downloaded, or exported outside of Dataverse, such as exporting data to Microsoft Excel or printing. Learn more about privacy-related privileges.
Each set of privilege types has its own tab. For each tab, you can filter the view by all privileges, assigned privileges, or unassigned privileges for the selected security role.
Table privileges
The Tables tab lists the Dataverse tables in the environment. The following table describes the attributes that are shown in the security role editor when the Compact Grid View option is off.
| Property | Description |
|---|---|
| Table | The name of the Dataverse table |
| Name | The logical name of the Dataverse table; helpful for developers |
| Record ownership | Whether records are owned by the organization or business unit or can be owned by a user or team |
| Permission Settings | Which predefined set of permissions the table is using, or custom permissions |
Tables are grouped into the following categories:
- Business Management
- Business Process Flows
- Core Records
- Custom Tables
- Customization
- Missing Tables
- Sales
- Service
- Service Management
To quickly find a specific table or privilege, enter its name in the search box at the upper-right corner of the page, and then select the magnifying glass icon or press Enter. To clear your search, select the X icon.
You can only edit one table at a time, but you can copy settings from one table to multiple tables in a single action.
When you configure a security role, you need to determine the privileges it should grant for each table that's related to the application.
The following table describes the table privileges you can grant in a security role. In all cases, which records a privilege applies to depends on the access level of the permission defined in the security role.
| Privilege | Description |
|---|---|
| Create | Required to make a new record |
| Read | Required to open a record to view the contents |
| Write | Required to make changes to a record |
| Delete | Required to permanently remove a record |
| Append | Required to associate the current record with another record; for example, if users have Append rights on a note, they can attach the note to an opportunity In the case of many-to-many relationships, a user must have Append privilege for both tables being associated or disassociated. |
| Append to | Required to associate a record with the current record; for example, if users have Append To rights on an opportunity, they can add a note to the opportunity |
| Assign | Required to give ownership of a record to another user |
| Share | Required to give access to a record to another user while keeping your own access |
Access levels
Each privilege has a menu that allows you to define its access level. Access levels determine how deep in the business unit hierarchy the user can perform the privilege.
The following table describes the levels of access. For organization-owned tables, miscellaneous privileges and privacy-related privileges only have access levels of Organization or None.
| Type | Description |
|---|---|
| Organization | 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. This level of access is usually reserved for managers with authority over the organization. |
| 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. This level of access is usually reserved for managers with authority over the business units. |
| 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. This level of access is usually reserved for managers with authority over the business unit. |
| 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. This is the typical level of access for sales and service representatives. |
| None | No access is allowed. |
For each table, select the appropriate type for each privilege. Select Save when you're finished.
Copy table permissions
Setting the privileges for each table in your app can be time-consuming and tedious. To make it easier, you can copy the permissions from one table to one or more others.
Select a table, and then select Copy table permissions
Search for and select the table or tables you want to copy the permissions to.
Remember, the new configuration overwrites any previous settings.
Select Save.
Let's take a closer look at how copy table permissions works with privileges and access levels.
For permissions that exist in both the source table and the target tables:
If the source permission settings depth exists in the target, then the copy is successful.
If the source permission settings depth doesn't exist in the target, then the copy fails and an error message is displayed.
For permissions that only exist in either the source table or the target tables:
If the permission exists in the source but not in the target, then it's ignored in the target. The copy for the remaining permissions is successful.
If the permission doesn't exist in the source but does exist in the target, then the depth of the permission is retained in the target. The copy for the remaining permissions is successful.
Permission settings
Another way to speed up the configuration of table permissions is to use predefined groups of permissions and assign them to tables.
The following table describes the permission setting groups that you can assign.
| Permission setting | Details |
|---|---|
| No Access | No users can access the table. |
| Full Access | Users can view and edit all records in the table. |
| Collaborate | Users can view all records, but they can only edit their own. |
| Private | Users can only view and edit their own records. |
| Reference | Users can only view records, not edit them. |
| Custom | Indicates that permission settings have been changed from the default value. |
Select a table, and then select Permission Settings in the command bar or select More Actions (…) > Permission Settings.
Select the appropriate setting.
Remember, the new configuration overwrites any previous settings.
Select Save.
Security roles and the legacy UI
Security roles define how different users access different types of records. To control access to data and resources, you can create or modify security roles and change the security roles that are assigned to your users.
A user can have multiple security roles. Security role privileges are cumulative. Users are granted the privileges that are available in each role that's assigned to them.
View a list of security roles in an environment (legacy UI)
Sign in to the Power Platform admin center, select Environments in the navigation pane, and then select an environment.
Select Settings > Users + Permissions > Security roles.
Define the privileges and properties of a security role (legacy UI)
After you've created a security role or while you're editing one, set the privileges associated with it.
A security role consists of record-level privileges and task-based privileges.
Record-level privileges define which tasks a user with access to the record can do, such as Read, Create, Delete, Write, Assign, Share, Append, and Append To. Append means to attach another record, such as an activity or note, to a record. Append to means to be attached to a record. Learn more about record-level privileges.
Miscellaneous privileges, or task-based privileges, give a user permission to perform specific, miscellaneous (non-record) tasks, such as publish articles or activate business rules. Learn more about miscellaneous privileges.
The colored circles on the security role settings page identify the access level assigned to each privilege. Access levels determine how deep in the business unit hierarchy the user can perform the privilege.
The following table describes the levels of access.
| Icon | Description |
|---|---|
 |
Global. Users can access all records in the organization, regardless of the business unit hierarchical level they or the environment belong to. Users who have Global access automatically have Deep, Local, and Basic access. Because this level gives access to information throughout the organization, it should be restricted to match the organization's data security plan. This level of access is usually reserved for managers with authority over the organization. The application refers to this access level as Organization. |
 |
Deep. Users can access records in their business unit and all business units subordinate to it. Users who have Deep access automatically have Local and Basic 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. This level of access is usually reserved for managers with authority over the business units. The application refers to this access level as Parent: Child Business Units. |
 |
Local. Users can access records in the user's business unit. Users who have Local access automatically have Basic 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. This level of access is usually reserved for managers with authority over the business unit. The application refers to this access level as Business Unit. |
 |
Basic. 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. This is the typical level of access for sales and service representatives. The application refers to this access level as User. |
 |
None. No access is allowed. |
Important
To make sure that users can view and access all areas of the web application, such as table forms, the navigation bar, and the command bar, all security roles in the organization must include the Read privilege on the Web Resource table. For example, without read permission, a user can't open a form that contains a web resource and sees an error message like this: "Missing prvReadWebResource privilege." Learn more about creating or editing a security role.
Record-level privileges
Power Apps and Dynamics 365 customer engagement apps use record-level privileges to determine the level of access a user has to a specific record or record type.
The following table describes the record-level privileges you can grant in a security role. In all cases, which records a privilege applies to depends on the access level of the permission defined in the security role.
| Privilege | Description |
|---|---|
| Create | Required to make a new record |
| Read | Required to open a record to view the contents |
| Write | Required to make changes to a record |
| Delete | Required to permanently remove a record |
| Append | Required to associate the current record with another record; for example, if users have Append rights on a note, they can attach the note to an opportunity In the case of many-to-many relationships, a user must have Append privilege for both tables being associated or disassociated. |
| Append to | Required to associate a record with the current record; for example, if users have Append To rights on an opportunity, they can add a note to the opportunity |
| Assign | Required to give ownership of a record to another user |
| Share* | Required to give access to a record to another user while keeping your own access |
*The owner of a record or a person who has the Share privilege on a record can share it with other users or teams. Sharing can add Read, Write, Delete, Append, Assign, and Share privileges for specific records. Teams are used primarily for sharing records that team members ordinarily can't access. Learn more about security, users, and teams.
It's not possible to remove access for a particular record. Any change to a security role privilege applies to all records of that type.
Team member's privilege inheritance
You can determine how privileges are inherited when a user is granted them as a member of a team or directly, as an individual.
User privileges: A 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 Basic access level for Create and Read was given to them. This setting is the default for new security roles.
Team privileges: A 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 Basic access level for Create and Read is given to them.
Note
Before the release of the team member's privilege inheritance feature in May 2019, security roles behaved as Team privileges. Security roles created before that release are set as Team privileges, and security roles created after it are by default set as User privileges.
A security role can be set to provide team members with direct Basic-level access privileges. When a privilege inheritance security role is assigned to a user, the user gets all the privileges directly, just like a security role without privilege inheritance. The team members can create records with themselves as the owner and records with the team as the owner when Basic access level for Create is given to them. When the Basic access level for Read is given to them, they can access records that are owned by both themselves and by the team. This privilege inheritance role applies to Owner and Microsoft Entra ID group teams.
Sign in to the Power Platform admin center, select Environments in the navigation pane, and then select an environment.
Select Settings > Users + permissions > Security roles.
Select New.
Enter the name of the new security role.
Select the Member's privilege inheritance list, and then select Direct User/Basic access level and Team privileges.
Go to each tab and set the appropriate privileges on each table.
To change the access level for a privilege, keep selecting the access level symbol until you see the one you want. The access levels available depend on whether the record type is organization-owned or user-owned.
You can only select Basic-level privileges in the member's privilege inheritance. If you need to provide access to a child business unit, elevate the privilege to Deep. For example, you need to assign a security role to the Group team and you want the members of the group to be able to Append to Account. Set up the security role with a Basic-level member's privilege inheritance. Set the Append to Account privilege to Deep. This is because Basic privileges apply only to the user's business unit.
Note
Since July 2024, the Team member's privilege inheritance attribute of a role is no longer a managed property. When you import a solution that has security roles, this attribute isn't included.