Security is a cornerstone of enterprise-grade business applications. When it comes to Microsoft Dynamics 365 and the Power Platform, Dataverse acts as the central data platform, offering a sophisticated and highly configurable security model. Two of its key components are Security Roles and Field-Level Security, which govern how users access, view, and interact with data.
This article dives deep into how Security Roles and Field-Level Security work in Microsoft Dataverse (formerly known as the Common Data Service), best practices for implementing them, and how they support secure, scalable, and compliant business solutions in both Dynamics 365 apps and Power Apps.
Understanding the Dataverse Security Model
Dataverse security is layered to provide granular control over data access. The main components are:
- Security Roles – Define permissions at the table (entity) and record level.
- Field-Level Security – Controls visibility, editing, and creation access at the field (column) level.
- Business Units – Help define hierarchy and segmentation of data access.
- Teams – Allow users to share access across functional or ad-hoc groups.
- Hierarchical Security – Enables managers to access records of their reports.
By using these in combination, organizations can ensure that data is available only to the right people, in the right contexts.
Part 1: Security Roles
What Are Security Roles?
Security Roles define what actions a user can perform on which tables (previously called entities) and records within Dataverse. Each user must be assigned at least one security role.
Security roles consist of privileges (e.g., Read, Write, Create) and access levels (e.g., User, Business Unit).
Key Actions in Security Roles
Each action you can control in a security role includes:
- Create – Add new records.
- Read – View existing records.
- Write – Modify existing records.
- Delete – Remove records.
- Append – Link a record to another.
- Append To – Allow other records to link to this record.
- Assign – Transfer ownership.
- Share – Grant access to others.
These permissions can be granted independently for each table in Dataverse.
Access Levels in Security Roles
Access levels determine the scope of the permissions:
| Access Level | Description |
|---|---|
| None | No access |
| User | Access to records the user owns |
| Business Unit | Access to records in the user’s business unit |
| Parent: Child Business Units | Access to records in the user’s business unit and child units |
| Organization | Access to all records across the tenant |
This model provides a flexible yet powerful system to grant different levels of access based on organizational hierarchy and responsibility.
Example: Salesperson Role
Let’s say you have a Salesperson role:
- Can create, read, and update Leads and Opportunities they own.
- Cannot delete Opportunities.
- Cannot access Cases (Customer Service module).
- Can view Accounts and Contacts at the business unit level.
This ensures users only interact with data relevant to their role, reducing risk and simplifying the UI experience.
Custom Security Roles
Administrators can create custom roles to match unique business needs. You can start from scratch or clone existing roles. This is particularly useful when building custom model-driven apps in Power Apps that don’t rely on traditional CRM modules.
Assigning Security Roles
Security roles are assigned at the user level, but access can also be granted through team membership. This allows for shared responsibilities and flexibility in managing access.
Viewing Security Roles
You can view and manage security roles from:
- Power Platform Admin Center (Environment > Settings > Security roles)
- Dynamics 365 Settings > Security
- Make.PowerApps.com (for environments using Dataverse)
Part 2: Field-Level Security
What Is Field-Level Security?
While Security Roles control access to entire tables and records, Field-Level Security (FLS) governs access to individual fields within a record.
Use FLS when:
- Sensitive information must be hidden from some users (e.g., salary, medical data).
- Specific fields should be editable only by certain roles.
- Compliance regulations require tighter control over PII (Personally Identifiable Information).
Field-Level Security Profiles
To implement field-level security:
- Enable the field for field-level security.
- Create a Field Security Profile.
- Add users or teams to the profile.
- Set permissions for each field:
- Read – View field value.
- Create – Enter a value during record creation.
- Update – Modify the field after creation.
Example: Employee Salary
Let’s say your HR system includes a Salary field on the Employee table:
- Only HR Managers should see and edit salary.
- Department Heads should only view salary.
- Regular users should not see the field at all.
You would:
- Enable field-level security on the Salary field.
- Create two profiles:
- HR Managers: Read, Create, Update
- Department Heads: Read only
- Assign users to the appropriate profile.
Business Units and Hierarchical Security
Business Units
Business Units are foundational for data segmentation in Dataverse. Every user belongs to one business unit, and roles can be defined to limit access by unit.
This is useful in:
- Franchises
- Multi-national companies
- Holding groups with semi-autonomous subsidiaries
Example: A user in the Canada business unit shouldn’t see leads owned by the US business unit.
Hierarchical Security
With Hierarchical Security, managers can be granted access to the records owned by their direct or indirect reports—even if they are in different teams or units.
Benefits:
- Mirrors org charts
- Reduces role complexity
- Automates access logic
Note: Hierarchical security must be enabled and configured explicitly.
Combining Security Roles and Field-Level Security
These systems are complementary. For example:
- A Sales Rep has read access to Opportunities.
- The “Discount Approved” field is hidden unless they are on the “Managers” FLS profile.
This gives you layered security control, allowing you to meet business, legal, and regulatory requirements.
Managing and Auditing Security
Tools for Admins
Admins can use:
- Security Role Viewer (to analyze permissions)
- Audit Logs (to track changes)
- PowerShell scripts (to report user access and cleanup)
- Power Platform Admin Center (for environment-wide visibility)
Best Practices
- Least privilege principle: Only grant access that’s necessary.
- Use teams for shared access scenarios.
- Review access regularly: especially after reorgs or role changes.
- Document your security model to ease onboarding and audits.
- Use layered security (record-level + field-level + business unit + teams).
Real-World Use Cases
1. Healthcare CRM
- Doctors see patient medical history.
- Nurses can update symptoms but not medications.
- Admins cannot access patient notes.
2. Finance Department App
- HR can edit employee compensation.
- Managers can view bonus fields.
- Staff cannot access these fields.
3. Customer Service Portal
- External agents can see only assigned cases.
- Internal employees can view organization-wide support issues.
Future of Security in Dataverse
Microsoft continues to enhance security features in the Power Platform:
- Support for Azure AD Conditional Access
- Environment-level DLP policies
- Support for Managed Environments
- Granular control over API calls and connectors
- Copilot integration with security-aware prompts
The roadmap includes more automation, centralized control, and integration with Microsoft Purview for compliance tracking.