PL400 : create or update security roles and field-level security profiles (Configure Microsoft Dataverse Security)

The security model is the key factor in Dataverse security that provides remarkable and extensible advantages in a competitive market. In the business world, data acts like fuel and data protection is a more formidable challenge than mining data in the current markets. It is important to build a security model that ensures proper use and access to valuable assets. One of the key features of Dataverse is its rich security model which can adapt to multiple business usage scenarios. This security model only comes into play if the environment contains a Dataverse database. Security Roles are fundamental unit  of data security in Dataverse.

The fundamental concept in role-based security is that roles have privileges that define a set of actions that can be performed within the organization.

In the security pyramid of Dataverse, Security Roles come as base security which protect the data as well as give the right access permission to authenticated users. Each security role consists of record-level privileges and task-based privileges.

Record-level privileges define what actions a user with access to the record can perform

Task-based privileges give privileges to the user to perform specific tasks

What is Privilege ?

Definition of a specific type of data access or action that can be granted to a security principal (user or team) and given through security roles.

Record-Level Privileges:

A security role is a combination of privileges and access levels. Record-level privilege refers to a user's permission with respect to a record in a Dataverse. Privilege defines the action (what can the user do?) and the access level refers to the degree of privileges.

Whereas, the privilege name is self explanatory and the access level gives the user the scope to take action. One quarter indicates user ownership is only on own records, two quarters indicates depth of scope meaning user can see all records which he/she belongs to business unit, three quarter urges that user can view same business unit with child business unit, four quarter or all selected indicates that these records are available for all users.

Task-based privileges:

Security roles have various task-based privileges that users can perform. In general, these privileges are turned on or off and are not based on business unit or other organizational considerations.

Team member’s privilege inheritance

User and Team privileges

User privileges: User is granted these privileges directly when a security role is assigned to the user. User can create and has access to records created/owned by the user when Basic access level for Create and Read were given.

Team privileges: User is granted these privileges as member of the team. For team members who do not have user privileges of their own, they can only create records with the team as the owner and they have access to records owned by the Team when Basic access level for Create and Read were given.

A security role can be set to provide a team member with direct Basic-level access user privileges. A team member can create records that they own and records that have the team as owner when the Basic access level for Create is given. When the Basic access level for Read is given, team member can access records that are owned by both that team member and by the team.

Important points :

• Each role must be assigned to a specific business unit.
• Roles created in a business unit are automatically inherited by each of its child business units.
• Moving a User to a new business unit will remove all the security roles associated with their account
• Inherited security roles can not be changed
• Multiple business units may each contain a role that has the same name, but the access levels for each privilege and record type may be completely different.
• We can create a copy of an existing security role.
• We can also set this privilege inheritance property for all out of the box security roles except the System Administrator.

Field-level Security:

Field-level security restricts access to a region of high business impact to specific users and teams. Field-level security is available for default fields on most out-of-box entities, custom fields, and custom fields on custom entities. Field-level security is managed by a security profile.

The scope of field-level security is organization-wide and applies to all data access requests including the following:

• Data Access requests from within a client application (Web browser, mobile client or Microsoft Dynamics 365 for Outlook).
• Web Service calls using the Microsoft Dataverse web services (for use in plugins, custom workflow activities and custom code).
• Reporting (using Filtered views).

The following steps describe how to restrict access to a field:

• Enable field-level security for an attribute
• Create a field-level security profile
• Associate users or teams to a profile
• Add specific field permissions for a specific attribute in a profile, such as Create, Update, or Read

A Security profile can be configured to grant user or team members the following permission at the field level:

• Read: Read-only access to the field's data.
• Create: Users or teams in this profile can add data to this field when creating a record.
• Update: Users or teams in this profile can update the field's data after it has been created.

All users with the System Administrator role are automatically added to a built-in field security profile called System Administrator.

Environment 's Security Roles and Dataverse 's Security Role :

Each environment has zero or one instance of Microsoft Dataverse database and each environment has two in built Security Role.

• Environment Admin 
• Environment Maker.

Environment Admin:

Under the environment, Environment Admin is powerful role which can  can perform all administrative tasks on the environment, including - add or remove users or groups, provision the Dataverse database, view and manage all resources, and set data loss prevention policies. After creating the database in the environment, we can use the System Administrator role instead of the Environment Admin Role.  System Administrator has full permission to customize or administer the environment, including creating, modifying, and assigning security roles and can view all data in the environment. 

Environment Maker:

User can create new resources associated with an environment, including apps, connections, custom APIs, gateways, and flows using Microsoft Power Automate. however, this role does not have any privileges to access data in an environment. They can share the app with individual users, security groups or all users in the organization

System Customizer:

The system optimizer has full permission to customize the environment. however, users with this role can only view records for the environment entities they have created.

Delegate:

Allows code to be impersonated, or run as another user. Usually used in conjunction with another security role to allow access to the record. Use impersonation to execute business logic on behalf of another Microsoft Dataverse user in order to provide the desired feature or service using the appropriate role and object-based security of that impersonated user.

Basic User:

The user can run an app within the environment and perform normal tasks for his own record. This only applies to non-custom entities.

Important links:

Team member’s privilege inheritance