Dataverse Security - Simply Explained

Welcome to another episode of Knowledge Nuggets with Mirko Peters. In this episode, we're exploring Microsoft Dataverse Security—one of the most important, and often misunderstood, aspects of the Power Platform. When people hear the word security, they usually think about passwords, authentication, or Microsoft Entra ID. While those components are important, Dataverse security goes much further. It determines who can perform actions, which records they can access, and even which individual fields they are allowed to see. Understanding these layers is essential for building secure enterprise applications that protect sensitive business information while allowing employees to work efficiently.

THE THREE LAYERS OF DATAVERSE SECURITY
Dataverse security is built around three distinct layers that work together. The first layer controls what actions users can perform. The second layer determines which records users are allowed to access. The third layer protects individual fields inside those records. Rather than relying on a single permission model, Dataverse combines these layers to provide highly granular security suitable for enterprise environments. Understanding how they interact is the key to designing secure Power Platform solutions. 

SECURITY ROLES – WHO CAN DO WHAT
Everything starts with Security Roles. Every Dataverse user must have at least one security role before they can access any data. Security roles define privileges such as:

• Create
• Read
• Write
• Delete
• Append
• Assign
• ShareMicrosoft provides several built-in roles, including:

• Basic User
• System Customizer
• Environment Maker
• System AdministratorMost organizations create custom roles by copying the Basic User role and adding only the permissions required for their own business tables. Following the principle of least privilege reduces security risks while keeping administration manageable.

ACCESS LEVELS – HOW MUCH DATA?
Granting permission to read data isn't enough. Dataverse also defines how much data a user may access through Access Levels. The four primary scopes are:

• User
• Business Unit
• Parent: Child Business Units
• OrganizationFor example, a salesperson might only see opportunities they own, while a sales manager can view opportunities belonging to everyone within the department. One important concept is that permissions are additive. If a user receives multiple security roles, Dataverse grants the broadest permission available. Additional roles never reduce existing permissions—they only increase them. Understanding this behavior helps administrators avoid accidentally granting more access than intended.

BUSINESS UNITS – ORGANIZING ACCESS
Business Units provide organizational separation. They typically represent departments such as:

• Sales
• Marketing
• Finance
• HR
• Customer SupportEvery user belongs to a default Business Unit, and records can also belong to Business Units. Historically, Business Units created strict organizational boundaries, limiting users to records owned by their own department. Modern Dataverse introduces a much more flexible matrix access model, allowing users to receive security roles from multiple Business Units. This enables cross-functional collaboration without forcing organizations to redesign their entire hierarchy whenever employees work across departments or regions.

TEAMS – SHARED OWNERSHIP
While Business Units organize departments, Teams simplify collaboration. Dataverse supports two primary team types. Owning Teams Owning Teams own records collectively. Instead of assigning ownership to a single employee, an entire team becomes responsible for the record. This works particularly well for sales teams, service desks, and project groups where multiple people collaborate continuously. Access Teams Access Teams don't own records. Instead, they provide temporary or scenario-specific access without transferring ownership. Microsoft also integrates Teams with Microsoft Entra ID security groups, allowing administrators to manage membership centrally while Dataverse automatically synchronizes permissions. This significantly reduces administrative effort in larger organizations. 

FIELD-LEVEL SECURITY
Sometimes protecting an entire record isn't enough. Sensitive information may exist in only one or two fields. Examples include:

• Salary
• Tax IDs
• Credit card numbers
• Social security numbers
• Banking detailsField-Level Security (FLS) protects individual columns inside a Dataverse table. Administrators create Field Security Profiles that specify which users or teams may:

• Read
• Update
• Createsecured fields. Even users with Organization-level table permissions cannot view secured columns unless they are explicitly included in the appropriate Field Security Profile. This makes FLS one of the most powerful security mechanisms available within Dataverse.

MASKING AND BEST PRACTICES
Recent D...