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
• Share

Microsoft provides several built-in roles, including:

• Basic User
• System Customizer
• Environment Maker
• System Administrator

Most 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
• Organization

For 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 Support

Every 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 details

Field-Level Security (FLS) protects individual columns inside a Dataverse table. Administrators create Field Security Profiles that specify which users or teams may:

• Read
• Update
• Create

secured 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 Dataverse enhancements introduced column masking, allowing organizations to partially display sensitive information. Instead of revealing an entire credit card number, users may only see the final four digits. Masking occurs on the server, ensuring consistent protection across forms, APIs, reports, and applications. Additional protections include:

• App Access Control
• Offline security
• Server-side enforcement
• Secure mobile synchronization

Microsoft recommends applying Field-Level Security only to truly sensitive columns because excessive use can increase complexity and affect performance. The recommended approach is:

1. Security Roles
2. Business Units and Teams
3. Field-Level Security only where necessary

Each layer should solve a specific problem rather than being applied everywhere

COMMON TROUBLESHOOTING SCENARIOS
Many Dataverse security issues follow familiar patterns. A common mistake is creating a custom security role while forgetting to assign the Basic User role, preventing users from accessing the environment. Another frequent misunderstanding involves additive permissions. Assigning another security role never removes existing permissions—it only grants additional access. Administrators should also verify:

• Business Unit ownership
• Team ownership
• Access Levels
• Field Security Profiles

A user may have full table permissions yet still be unable to view a field because Field-Level Security overrides table-level access for secured columns. Knowing where to investigate dramatically reduces troubleshooting time.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.