Dataverse security roles explained
Security is one of the most important aspects of any Dataverse implementation. A well-designed security model ensures that users see exactly the data they need, no more and no less. In this article, we take you from basic concepts to advanced configurations needed for enterprise implementations.
The Dataverse security model
Dataverse uses a layered security model consisting of multiple components. At its core are security roles that determine what permissions a user has at the table and field level. These roles are assigned via business units, teams, or directly to individual users. The model follows the principle of least privilege: users receive no access by default, and you explicitly add permissions.
Business units and teams
Business units as structure
Business units form the organizational structure within Dataverse. Each environment has a root business unit under which you can create departments, regions, or divisions. A user always belongs to exactly one business unit. Records created by a user are automatically linked to their business unit. This is fundamental to how security roles determine data visibility.
Teams for flexibility
Where business units are rigid, teams offer flexibility. A user can be a member of multiple teams, each with their own security roles. Dataverse supports owner teams (which can own records), access teams (dynamically composed based on templates), and Azure AD group teams (synchronized with Entra ID groups). Group teams are particularly powerful because they automatically synchronize with your identity provider, significantly simplifying management.
Configuring security roles
A security role defines permissions at four levels: Create, Read, Write, Delete, Append, Append To, Assign, and Share. Each permission can be set to five scopes: User (own records only), Business Unit, Parent-Child Business Units, Organization (all records), and None (no access). When designing roles, it is important to start with the minimum permissions a user needs and only expand where necessary.
For Dynamics 365 Sales, there are predefined roles such as Salesperson and Sales Manager that provide a good starting point. However, it is strongly recommended never to edit the default roles directly. Always create copies and customize those, so Microsoft updates do not overwrite your modifications.
Always start with the principle of least privilege. It is easier to add permissions than to discover after the fact that users had access to data they should not have seen.
Field-level security and hierarchy
Field-level security
Sometimes table-level security is not enough. Field-level security allows you to secure individual columns. For example, a salesperson may view customer records but not the annual revenue field. You configure this via field security profiles that you assign to users or teams. Keep in mind that field-level security can have a performance impact on large datasets, so use it thoughtfully.
Hierarchical security
Dataverse supports two types of hierarchy: manager hierarchy and position hierarchy. With manager hierarchy, a manager automatically gains read access to records of direct and indirect reports. Position hierarchy offers more flexibility as it is independent of the organizational structure. This is particularly useful for matrix organizations where reporting lines do not always reflect the actual collaboration structure.
Best practices and common mistakes
The most common mistake we encounter at Breathbase is assigning the System Administrator role to too many users. This role grants full access to everything and should be strictly limited to actual administrators. Another common mistake is not testing security roles with realistic test data. Take the time to walk through each scenario and verify that users have exactly the right access. A solid security model is the foundation of every successful Dynamics 365 implementation.
