Security Roles & Permissions
Security Roles & Permissions in Microsoft Dataverse
Microsoft Dataverse provides a strong and flexible security model that controls who can access data, what actions users can perform, and how far their access should reach. In business applications, security is extremely important because Dataverse may store sensitive information such as employee records, customer details, sales opportunities, cases, financial data, approval history, and confidential business records.
Dataverse uses role-based security to group a collection of privileges into security roles. These security roles can be assigned directly to users or associated with teams and business units. Users can then receive access through direct role assignment or through team membership. [1](https://learn.microsoft.com/en-us/power-platform/admin/wp-security-cds)
In simple words, Security Roles & Permissions answer the following questions:
- Who can access the data?
- Which tables can the user access?
- Which records can the user see?
- Can the user create, read, update, or delete records?
- Can the user assign or share records?
- Can the user access only their own records, team records, business unit records, or all organization records?
- Can the user access sensitive columns such as salary, credit limit, or confidential comments?
1. What is Security in Dataverse?
Security in Dataverse means controlling access to data and resources. It ensures that users can only perform the actions they are allowed to perform. For example, an employee may be allowed to create a leave request, but only a manager should be allowed to approve it. Similarly, a salesperson may view their own leads, while a sales manager may view leads for the entire team.
Microsoft Dataverse security includes role-based security, business units, table ownership, record ownership, teams, record sharing, record-level security, and column-level security. [1](https://learn.microsoft.com/en-us/power-platform/admin/wp-security-cds)
| Security Area | Purpose | Example |
|---|---|---|
| Role-Based Security | Controls access using security roles and privileges. | Employee User, Manager, HR Admin |
| Business Unit Security | Controls data access based on business unit boundaries. | India Sales BU, US Sales BU |
| Record-Level Security | Controls access to individual records. | User can see only records they own. |
| Column-Level Security | Controls access to specific fields/columns. | Only HR can view Salary column. |
| Team-Based Security | Provides access to users through team membership. | Support Team gets access to support cases. |
| Sharing | Allows individual records to be shared with users or teams. | Share a customer record with another sales user. |
2. What is a Security Role?
A Security Role is a collection of privileges that defines what a user can do in Dataverse. Security roles define how different users access different types of records. To control access to data and resources, administrators can create or modify security roles and assign them to users. [2](https://learn.microsoft.com/en-us/power-platform/admin/security-roles-privileges)
A user can have multiple security roles. The privileges from multiple roles are cumulative, meaning Dataverse combines the permissions from all assigned roles and grants the greatest level of access available from those roles. [2](https://learn.microsoft.com/en-us/power-platform/admin/security-roles-privileges)[1](https://learn.microsoft.com/en-us/power-platform/admin/wp-security-cds)
Simple Example
Suppose a user has two security roles:
- Role 1: Can read customer records.
- Role 2: Can update customer records.
Because Dataverse permissions are cumulative, the user can both read and update customer records.
| Role | Permission | Final Result |
|---|---|---|
| Sales Reader | Read customer records | User can read and update customer records. |
| Sales Editor | Update customer records |
3. Why Security Roles are Important
Security roles are important because they protect sensitive data and ensure that users work only within their authorized responsibilities. Dataverse security roles are used to control who can access restricted or sensitive data and what they can do with that data. [2](https://learn.microsoft.com/en-us/power-platform/admin/security-roles-privileges)
| Reason | Explanation | Example |
|---|---|---|
| Data Protection | Prevents unauthorized users from viewing or changing sensitive business data. | Only HR users can see employee salary details. |
| Business Process Control | Ensures users perform only the actions allowed for their role. | Employees submit leave requests, managers approve them. |
| Data Accuracy | Reduces accidental or unauthorized updates. | Read-only users cannot modify customer records. |
| Compliance | Supports organizational governance and data access policies. | Finance data is restricted to finance users. |
| Application Security | Controls Dataverse data used by Power Apps, Power Automate, Power BI, Power Pages, and Copilot Studio. | Only approved users can access business application data. |
4. Core Components of Dataverse Security
Dataverse security is built using several components that work together. Security is not controlled by one single setting. It depends on roles, privileges, access levels, business units, users, teams, ownership, sharing, and column-level security. [1](https://learn.microsoft.com/en-us/power-platform/admin/wp-security-cds)
| Component | Description | Example |
|---|---|---|
| Security Role | A group of privileges assigned to users or teams. | Sales User, HR Manager, Support Agent |
| Privilege | The action a user can perform on a table. | Create, Read, Write, Delete |
| Access Level | The scope or depth of the privilege. | User, Business Unit, Organization |
| Business Unit | A security boundary for users and records. | Sales India BU, HR BU |
| User | An individual person who accesses the environment. | Employee, Manager, Admin |
| Team | A group of users that can receive roles and own records. | Support Team, Sales Team |
| Owner | The user or team that owns a record. | A case owned by a support agent. |
| Sharing | Allows specific record access to another user or team. | Share one opportunity with another salesperson. |
| Column-Level Security | Restricts access to selected columns. | Protect salary or credit limit field. |
5. Security Privileges in Dataverse
Privileges define what a user is allowed to do with records. Common Dataverse privileges include Create, Read, Write, Delete, Append, Append To, Assign, and Share. These are configured for each table inside security roles. [3](https://www.preciofishbone.com/knowledge-hub/dataverse-security-roles-privileges-access-levels/)[4](https://thedataversedev.com/blog/dataverse-security-model)
| Privilege | Meaning | Real-Life Example |
|---|---|---|
| Create | Allows the user to create a new record. | Create a new leave request. |
| Read | Allows the user to view an existing record. | View customer details. |
| Write | Allows the user to update an existing record. | Edit customer phone number. |
| Delete | Allows the user to delete a record. | Delete an old test record. |
| Append | Allows the current record to be attached to another record. | Add a note or activity to another record. |
| Append To | Allows another record to be attached to the current record. | Allow notes to be attached to a case. |
| Assign | Allows the user to change the owner of a record. | Assign a ticket to another support agent. |
| Share | Allows the user to share a record with another user or team. | Share a sales opportunity with another salesperson. |
Important Note: Append vs Append To
Append and Append To are commonly confusing. Append means the user can attach a record to another record. Append To means another record can be attached to the current record. For example, to create a note on a case, a user may need Append permission on Notes and Append To permission on Cases. [4](https://thedataversedev.com/blog/dataverse-security-model)
6. Access Levels in Security Roles
Access levels define the scope of a privilege. A user may have Read permission, but the access level decides whether the user can read only their own records, records in their business unit, records in child business units, or all records in the organization. [1](https://learn.microsoft.com/en-us/power-platform/admin/wp-security-cds)[4](https://thedataversedev.com/blog/dataverse-security-model)
| Access Level | Description | Example |
|---|---|---|
| None | No access for that privilege. | User cannot read leave requests. |
| User | Access only to records owned by the user. | Employee can see only their own leave requests. |
| Business Unit | Access to records owned by users in the same business unit. | Sales manager can see records in Sales India BU. |
| Parent: Child Business Units | Access to records in the user's business unit and child business units. | Regional head can see records in regional child units. |
| Organization | Access to all records across the environment. | System administrator can access all records. |
7. Business Units in Dataverse Security
A Business Unit is a security boundary used to manage users and data access. Every Dataverse database has a single root business unit. Child business units can be created to further segment users and data. Every user assigned to an environment belongs to a business unit. [1](https://learn.microsoft.com/en-us/power-platform/admin/wp-security-cds)
Business units are commonly used when organizations want to separate data access by region, department, branch, function, or business division.
| Business Unit Concept | Meaning | Example |
|---|---|---|
| Root Business Unit | Main business unit created for the environment. | Contoso Organization |
| Child Business Unit | Business unit created under another business unit. | India Sales, US Sales |
| Security Boundary | Controls how far users can access records. | India users see India records only if configured that way. |
| User Membership | Each user belongs to a business unit. | A sales executive belongs to India Sales BU. |
Business Unit Example
| Business Unit | User Type | Access Requirement |
|---|---|---|
| India Sales | Salesperson | Can access own sales records. |
| India Sales | Sales Manager | Can access sales records in India Sales BU. |
| Asia Region | Regional Manager | Can access parent and child business unit records. |
8. Teams in Dataverse Security
Security roles can be assigned to teams. Users who are members of a team can benefit from the roles assigned to that team. This helps administrators manage permissions for groups of users instead of assigning roles one by one. [1](https://learn.microsoft.com/en-us/power-platform/admin/wp-security-cds)
Teams are useful when multiple users need the same access or when records should be owned by a group.
| Team Type / Usage | Description | Example |
|---|---|---|
| Owner Team | A team that can own records and receive security roles. | Support Team owns support cases. |
| Access Team | Provides access to specific records without owning them. | A project team gets access to one project record. |
| Group-Based Access | Permissions are managed by team membership. | Adding a user to Sales Team gives sales permissions. |
9. User Privileges vs Team Privileges
Microsoft documentation explains that a user can receive privileges directly through a security role assigned to the user, or indirectly as a member of a team. It also describes privilege inheritance options such as team privileges only and direct user plus team privileges. [2](https://learn.microsoft.com/en-us/power-platform/admin/security-roles-privileges)
| Type | Meaning | Example |
|---|---|---|
| Direct User Privileges | The role is assigned directly to an individual user. | HR Manager role assigned directly to Priya. |
| Team Privileges | The user receives permissions because they are part of a team. | All Support Team members get case access. |
| Combined Privileges | User receives access from both direct roles and team roles. | A manager has personal manager access and team-based access. |
10. Table Ownership and Security
Table ownership affects the type of security that can be applied. Dataverse supports organization-owned tables and user/team-owned tables. User/team-owned tables support ownership-based access, while organization-owned tables are used for data that is not owned by individual users or teams. [1](https://learn.microsoft.com/en-us/power-platform/admin/wp-security-cds)
| Ownership Type | Description | Best Use Case |
|---|---|---|
| Organization-Owned Table | Records are owned by the organization rather than individual users or teams. | Reference data, system settings, global configuration |
| User/Team-Owned Table | Records are owned by a specific user or team. | Cases, opportunities, leave requests, tasks |
Example
| Table | Recommended Ownership | Reason |
|---|---|---|
| Country Master | Organization-Owned | Same reference data can be used by all users. |
| Leave Request | User/Team-Owned | Each leave request belongs to a specific employee or team. |
| Support Ticket | User/Team-Owned | Each ticket may be assigned to a support agent or support team. |
11. Record-Level Security
Record-level security controls access to individual rows or records. In Dataverse, access to records depends on security roles, access levels, ownership, business units, teams, and sharing. [1](https://learn.microsoft.com/en-us/power-platform/admin/wp-security-cds)
For example, a salesperson may be able to view only their own leads, while a sales manager may view leads owned by users in the same business unit.
| User Type | Access Requirement | Possible Configuration |
|---|---|---|
| Employee | Can view only own records. | Read privilege at User level. |
| Manager | Can view team or department records. | Read privilege at Business Unit level. |
| Regional Head | Can view records in parent and child business units. | Read privilege at Parent: Child Business Units level. |
| Administrator | Can view all records. | Read privilege at Organization level. |
12. Column-Level Security
Column-level security controls access to specific columns instead of the whole table. This is useful when most users can access a table but only selected users should view or edit sensitive fields. Dataverse security concepts include column-level security as part of the overall security model. [1](https://learn.microsoft.com/en-us/power-platform/admin/wp-security-cds)
| Scenario | Sensitive Column | Who Should Access? |
|---|---|---|
| Employee Management | Salary | HR Manager and Finance Team |
| Customer Management | Credit Limit | Finance Users |
| Approval Process | Manager Comments | Approvers only |
| Support Case | Confidential Notes | Authorized support leads only |
13. Record Sharing
Record sharing allows a specific record to be shared with another user or team. Sharing is useful when a user does not normally have access to a record, but temporary or special access is required.
| Sharing Scenario | Example | Purpose |
|---|---|---|
| Temporary Collaboration | Share one opportunity with another salesperson. | Allows collaboration without changing full role permissions. |
| Manager Review | Share a support ticket with a senior manager. | Allows review of a specific case. |
| Cross-Team Support | Share customer issue with technical team. | Allows another team to assist with a record. |
14. Hierarchy Security
Hierarchy security is used when access should follow a management or position structure. It can help managers access records owned by users below them in the hierarchy. This is useful for reporting, approvals, reviews, and supervisory access.
| Hierarchy Example | Access Requirement |
|---|---|
| Employee | Can access own records. |
| Manager | Can access records of team members. |
| Regional Head | Can access records of managers and teams under the region. |
15. Security Roles in Model-Driven Apps
In model-driven apps, users must have proper security roles to access the app and the underlying Dataverse tables. Even if an app is shared with a user, the user still needs the required table privileges to view or work with Dataverse data.
| Requirement | Explanation |
|---|---|
| App Access | User must be allowed to open the model-driven app. |
| Table Permission | User must have privileges on the Dataverse tables used by the app. |
| Record Access | User must have access level permission to required records. |
| Column Access | User may need column-level security access for protected columns. |
16. Security Role Example: Leave Approval System
Let us understand security roles using an Employee Leave Approval System.
Business Requirement
- Employees can create leave requests.
- Employees can view their own leave requests.
- Employees cannot approve their own leave requests.
- Managers can view leave requests of their team.
- Managers can approve or reject leave requests.
- HR can view all leave records.
- Only HR can update leave balance.
- System administrators can manage configuration and security.
Suggested Roles
| Security Role | Description | Access Scope |
|---|---|---|
| Employee User | Basic user who submits leave requests. | User-level access |
| Manager | Approves or rejects leave requests for team members. | Business Unit-level access |
| HR User | Manages leave records and leave balances. | Organization-level access where required |
| System Administrator | Manages application configuration and security. | Full environment-level access |
17. Permission Matrix: Leave Approval System
A permission matrix is a useful design document that clearly shows which role has which permission on each table.
| Table | Role | Create | Read | Write | Delete | Assign | Share |
|---|---|---|---|---|---|---|---|
| Leave Request | Employee | User | User | User | None | None | None |
| Leave Request | Manager | None | Business Unit | Business Unit | None | None | User |
| Leave Request | HR User | Organization | Organization | Organization | None | Organization | Organization |
| Leave Balance | Employee | None | User | None | None | None | None |
| Leave Balance | HR User | Organization | Organization | Organization | None | None | None |
18. Security Role Example: Customer Support Portal
Now let us take another real-life example: a Customer Support Portal built using Power Pages, Power Apps, Power Automate, and Dataverse.
Tables
- Customer
- Support Ticket
- Ticket Comment
- Support Agent
- Ticket Category
Security Requirements
- Customers can create support tickets.
- Customers can view only their own tickets.
- Support agents can view tickets assigned to them.
- Support managers can view all tickets for their team.
- Administrators can manage all tickets and configuration data.
| Role | Access Requirement | Suggested Scope |
|---|---|---|
| Customer | Create and view own support tickets. | User or portal-specific access configuration |
| Support Agent | Read and update tickets assigned to them. | User-level access |
| Support Manager | View and manage tickets for the support team. | Business Unit-level access |
| Administrator | Manage all records and settings. | Organization-level access |
19. Security Roles and Power Platform Components
Dataverse security affects how data is accessed from different Power Platform components.
| Component | How Security Roles Matter | Example |
|---|---|---|
| Power Apps | Controls which Dataverse records users can view, create, or edit. | Employee can update only own leave request. |
| Power Automate | Flows working with Dataverse must use appropriate permissions through their connection context. | Approval flow updates leave request status. |
| Power BI | Reports should be designed according to data security requirements. | Manager dashboard shows team data only. |
| Power Pages | External users need properly controlled access to Dataverse data. | Customer sees only own tickets. |
| Copilot Studio | Bots connected to Dataverse should follow secure data access design. | Bot retrieves only authorized customer data. |
20. Security Design Process
A good Dataverse security design should be planned before building the application.
| Step | Action | Example |
|---|---|---|
| Step 1 | Identify user groups. | Employee, Manager, HR, Admin |
| Step 2 | Identify tables used in the application. | Employee, Leave Request, Leave Balance |
| Step 3 | Define what each role can do. | Employee can create leave request. |
| Step 4 | Define access level for each privilege. | User-level Read for Employee role. |
| Step 5 | Decide business unit and team structure. | Sales BU, HR BU, Support Team |
| Step 6 | Protect sensitive columns. | Salary column visible only to HR. |
| Step 7 | Test access using sample users. | Check whether employee can see only own records. |
21. Best Practices for Security Roles & Permissions
Microsoft guidance recommends following Dataverse best practices when customizing, extending, or integrating with Dataverse to improve performance, security, and supportability. [5](https://learn.microsoft.com/en-us/power-apps/developer/data-platform/best-practices/)
| Best Practice | Explanation | Example |
|---|---|---|
| Follow least privilege | Give users only the permissions required for their work. | Employee should not get Organization-level Delete access. |
| Use meaningful role names | Role names should clearly describe their purpose. | Leave Approver, HR Data Manager, Sales Reader |
| Avoid over-permissioning | Too much access increases security risk. | Do not give all users System Administrator role. |
| Use teams for group access | Teams simplify permission management. | Assign support permissions to Support Team. |
| Plan business units early | Business units affect data visibility and access scope. | Create regional BUs before configuring access rules. |
| Use column-level security for sensitive data | Protect confidential fields without hiding the entire table. | Protect salary, credit limit, confidential notes. |
| Document permission matrix | Clear documentation helps with maintenance and audits. | Maintain role-wise table permission matrix. |
| Test with real user scenarios | Security should be validated before production release. | Login as employee, manager, and HR test users. |
| Review security regularly | User responsibilities change over time. | Remove old permissions when users change roles. |
22. Common Mistakes in Dataverse Security Design
| Mistake | Problem | Better Approach |
|---|---|---|
| Giving Organization-level access to everyone | Users may see or edit records they should not access. | Use User, Business Unit, or Parent: Child scope where appropriate. |
| Using one role for all users | Different job responsibilities need different permissions. | Create separate roles for employee, manager, HR, and admin. |
| Ignoring business units | Data visibility may not match organizational structure. | Design business units based on access boundaries. |
| Not using teams | Managing individual users becomes difficult. | Use teams for common group access. |
| Not protecting sensitive columns | Users may access confidential fields. | Use column-level security. |
| No permission matrix | Security becomes difficult to understand and maintain. | Create clear permission documentation. |
| Not testing security | Users may get too much or too little access after deployment. | Test with sample users for each role. |
23. Difference Between Security Role, Business Unit, Team, and Sharing
| Feature | Main Purpose | Example |
|---|---|---|
| Security Role | Defines what actions users can perform. | Create, Read, Write, Delete permissions |
| Business Unit | Defines security boundary and access scope. | India Sales BU |
| Team | Groups users for shared permissions or ownership. | Support Team |
| Sharing | Grants access to a specific record. | Share one customer record with another user. |
24. Quick Revision Table
| Concept | Simple Meaning | Important Point |
|---|---|---|
| Security Role | Collection of permissions. | Can be assigned to users or teams. |
| Privilege | Action allowed on a table. | Create, Read, Write, Delete, Append, Assign, Share. |
| Access Level | Scope of the permission. | User, BU, Parent: Child BU, Organization. |
| Business Unit | Security boundary. | Every user belongs to a business unit. |
| Team | Group of users. | Can receive security roles. |
| Record Ownership | Who owns a record. | User or team can own records. |
| Column-Level Security | Protects specific fields. | Used for sensitive columns. |
25. Interview Questions and Answers
Q1. What is a security role in Dataverse?
A security role is a collection of privileges that controls what users can do with Dataverse data and resources. Security roles define how different users access different types of records. [2](https://learn.microsoft.com/en-us/power-platform/admin/security-roles-privileges)
Q2. Can a user have multiple security roles?
Yes. A user can have multiple security roles. Security role privileges are cumulative, so the user receives the combined access from all assigned roles. [2](https://learn.microsoft.com/en-us/power-platform/admin/security-roles-privileges)[1](https://learn.microsoft.com/en-us/power-platform/admin/wp-security-cds)
Q3. What are the common privileges in Dataverse security roles?
Common privileges include Create, Read, Write, Delete, Append, Append To, Assign, and Share. These privileges define what actions a user can perform on table records. [3](https://www.preciofishbone.com/knowledge-hub/dataverse-security-roles-privileges-access-levels/)[4](https://thedataversedev.com/blog/dataverse-security-model)
Q4. What is the difference between Append and Append To?
Append allows a record to be attached to another record. Append To allows another record to be attached to the current record. For example, adding a note to a case may require Append on Notes and Append To on Cases. [4](https://thedataversedev.com/blog/dataverse-security-model)
Q5. What is an access level in Dataverse?
An access level defines how far a privilege applies. Examples include None, User, Business Unit, Parent: Child Business Units, and Organization. [1](https://learn.microsoft.com/en-us/power-platform/admin/wp-security-cds)[4](https://thedataversedev.com/blog/dataverse-security-model)
Q6. What is a business unit in Dataverse?
A business unit is a security boundary used to manage users and data access. Every user assigned to an environment belongs to a business unit. [1](https://learn.microsoft.com/en-us/power-platform/admin/wp-security-cds)
Q7. What is the difference between user-level and organization-level access?
User-level access allows users to access only records they own. Organization-level access allows users to access records across the entire environment. [4](https://thedataversedev.com/blog/dataverse-security-model)
Q8. What is column-level security?
Column-level security restricts access to specific columns in a table. It is useful for sensitive fields such as salary, credit limit, or confidential notes. [1](https://learn.microsoft.com/en-us/power-platform/admin/wp-security-cds)
Q9. Why should we use teams in Dataverse security?
Teams help manage permissions for groups of users. Instead of assigning roles individually, administrators can assign roles to a team and manage access through team membership. [1](https://learn.microsoft.com/en-us/power-platform/admin/wp-security-cds)
Q10. What is the principle of least privilege?
The principle of least privilege means users should receive only the minimum permissions required to perform their work. This reduces security risk and prevents unnecessary access.
26. Student-Friendly Summary
| Topic | Easy Explanation | Example |
|---|---|---|
| Security Role | A permission set given to a user or team. | Manager Role |
| Privilege | The action the user can perform. | Create, Read, Write |
| Access Level | How much data the user can access. | Own data or all company data |
| Business Unit | A boundary for data access. | India Sales Department |
| Team | A group of users with shared access. | Support Team |
| Record-Level Security | Controls individual record access. | Employee sees own leave request only. |
| Column-Level Security | Protects specific fields. | Only HR sees salary. |
Conclusion
Security Roles and Permissions are one of the most important parts of Microsoft Dataverse. They define who can access data, what actions users can perform, and how much data they can access. Dataverse security works through security roles, privileges, access levels, business units, teams, ownership, sharing, record-level security, and column-level security. [2](https://learn.microsoft.com/en-us/power-platform/admin/security-roles-privileges)[1](https://learn.microsoft.com/en-us/power-platform/admin/wp-security-cds)
A well-designed security model protects sensitive data, supports business processes, improves governance, and helps users work safely within their responsibilities. In any real-world Power Platform project, security should be planned before building apps, flows, reports, portals, or chatbots.
The best approach is to identify user roles, define required permissions, apply the principle of least privilege, use teams and business units properly, protect sensitive columns, document the permission matrix, and test security with different user scenarios before production deployment.