July 21, 2026

Dataverse Security - Simply Explained

Dataverse Security is the foundation that protects business data across the Microsoft Power Platform. In this episode of Microsoft Knowledge Nuggets, Mirko Peters explains Dataverse Security in simple terms, showing how Microsoft enables organizations to control exactly who can view, edit, create, or delete data while maintaining enterprise-grade governance, compliance, and scalability. Unlike traditional databases, security is built directly into the platform rather than added afterwards.

You'll learn how Dataverse uses a layered security model based on Microsoft Entra ID authentication, business units, security roles, teams, ownership, and role-based access control (RBAC). The episode explains record-level security, row-level permissions, column-level security, field security profiles, hierarchy security, and how permissions are inherited across Power Apps, Power Automate, Dynamics 365, and other Microsoft business applications. This security model allows organizations to protect sensitive business information while ensuring users only access the data they need.

In today's digital landscape, protecting your data is crucial. You face various challenges that threaten sensitive information. Understanding Dataverse Security helps you safeguard your data effectively. This knowledge empowers you to implement robust measures that enhance data protection. By prioritizing security, you can ensure your organization operates smoothly and securely.

Key Takeaways

Understanding Dataverse Security is essential for protecting sensitive data in your organization.
Implement role-based security to define user permissions and create custom roles tailored to your needs.
Utilize field-level security to restrict access to specific data fields, safeguarding sensitive information.
Conduct regular security audits to identify vulnerabilities and ensure compliance with security policies.
Provide user training to enhance security awareness and reduce the likelihood of security incidents.
Keep your Dataverse software updated to benefit from the latest security features and patches.
Adopt measures against phishing attacks, such as multifactor authentication and continuous security audits.
Stay informed about emerging technologies and trends that can enhance your Dataverse security practices.

What Is Dataverse Security?

Overview of Microsoft Dataverse

Microsoft Dataverse serves as a robust data platform that underpins the Power Platform. It provides a secure and scalable environment for building enterprise applications. At its core, dataverse security encompasses a rich security model designed to protect data integrity and user privacy. You can combine various security features, such as role-based security, row-based security, and column-based security, to define user access to information effectively. This layered approach ensures that users can collaborate efficiently while maintaining strict control over sensitive data.

Importance of Security in Dataverse

Understanding dataverse security is crucial for organizations that prioritize data protection. Here are some key reasons why you should focus on security in Dataverse:

Role-based Security: Pre-defined roles govern user permissions. This allows you to create custom roles tailored to your organization's needs.
Field-level Security: This feature limits access to specific fields within a table, which is vital for managing sensitive data.
Integration with Azure AD: This integration provides a secure foundation for managing user access and safeguarding data.

By implementing these features, you can minimize risks and enhance user adoption. Additionally, Data Loss Prevention (DLP) policies establish guardrails for connector usage, ensuring that sensitive data remains protected.

Dataverse auditing enables you to track user activity and data changes. This capability facilitates faster investigations and supports compliance workflows. Organizations that prioritize security and regulatory adherence find this feature essential.

Moreover, Microsoft Dataverse integrates seamlessly with other Microsoft security solutions. This integration offers unified visibility and threat detection. For instance, Dataverse audit events can be ingested into Microsoft Sentinel, allowing for correlation with other security signals. This capability enhances your ability to respond quickly to potential threats.

Dataverse Security Components

Understanding the components of dataverse security is essential for protecting your organization's data. The security framework consists of three main layers: security roles, access levels, and field-level security. Each layer plays a crucial role in ensuring that sensitive information remains secure while allowing users to perform their tasks effectively.

Security Roles

Definition and Purpose

Security roles define what actions you can perform on data tables within Dataverse. They control permissions for creating, reading, updating, and deleting records. By assigning specific roles to users, you can ensure that they only access the data necessary for their job functions. This approach minimizes the risk of unauthorized access and enhances overall security.

Built-in vs. Custom Roles

Microsoft Dataverse provides several built-in security roles, including:

App Opener
Basic User
Delegate
Dynamics 365 Administrator
Environment Maker
Global Administrator
Global Reader
Office Collaborator
Power Platform Administrator
Service Deleted
Service Reader
Service Writer
Support User
System Administrator
System Customizer
Website App Owner
Website Owner

While these roles cover many common scenarios, you can also create custom roles tailored to your organization's specific needs. Custom roles allow you to follow the principle of least privilege, ensuring users have only the access necessary for their responsibilities.

Access Levels

Hierarchical Structure

Access levels in Dataverse establish a hierarchical structure that determines data visibility based on user roles. This structure allows you to control which records users can access. For example, a Sales Manager may view records from their own Business Unit but not from others, depending on their security role configuration.

Role-Specific Data Visibility

The following table outlines the different access levels provided by Dataverse security roles:

Access Level	Description
Organization	Users can access all records in the organization, regardless of their business unit.
Parent: Child Business Unit	Users can access records in their business unit and all subordinate business units.
Business Unit	Users can access records in their business unit.
User	Users can access records they own and those shared with them or their teams.
None	No access is allowed.

This hierarchical organization ensures that data visibility aligns with your organization's security policies.

Field-Level Security

Protecting Sensitive Information

Field-level security adds another layer of protection by allowing you to secure individual fields within records. This feature is crucial for safeguarding sensitive information, such as social security numbers or financial data. By restricting access to specific fields, you can ensure that only authorized personnel can view or modify this information.

Implementing Field Security Profiles

To implement field-level security effectively, follow these steps:

Enable Column Security for the desired field (e.g., PIN field).
Access Advanced Settings and create a Field Security Profile with a name and description.
Set Field Permissions for the enabled field with options to Allow Read, Allow Update, and Allow Create.
Assign the profile to users or teams as needed.

By combining security roles, access levels, and field-level security, you create a comprehensive security framework that protects your organization's data. This layered approach ensures that sensitive information remains secure while allowing users to collaborate effectively.

Best Practices for Dataverse Security

Regular Security Audits

Conducting regular security audits is essential for maintaining a strong security posture in your Dataverse environment. These audits help you identify vulnerabilities and ensure compliance with your organization's security policies. You can use various tools to automate these audits, making the process more efficient. Here are some key tools to consider:

Tool/Feature	Description
Role-Based Security	Groups privileges and manages access effectively, ensuring users have necessary permissions.
Filtered View-Based Security Model	Provides row-level access control, restricting data visibility based on user roles.
Column-Level Security	Masks sensitive data, preventing unauthorized users from viewing critical information.
Data Loss Prevention (DLP) Policies	Helps prevent unintentional data exposure by controlling data sharing and access.

Regular audits not only enhance accountability but also help you track data access and modifications. This proactive approach allows you to respond quickly to potential threats and maintain a secure environment.

User Training and Awareness

User training plays a vital role in enhancing security awareness within your organization. Educating users about security policies and best practices can significantly reduce the likelihood of security incidents. Here are some effective training topics to cover:

Awareness of Security Policies: Ensure users understand acceptable use and data handling procedures.
Recognizing Phishing Attempts: Train users to identify phishing emails and suspicious links.
Best Practices for Password Management: Encourage strong, unique passwords and the use of password managers.
Utilizing Power Apps Securely: Provide guidance on the secure usage of Power Apps and the importance of data privacy.
Incident Reporting Procedures: Establish clear procedures for reporting security incidents.

Consider implementing interactive training sessions led by experts. These sessions can use real-life examples to engage users effectively. Ongoing education and refreshers keep security awareness current, fostering a culture of shared responsibility among employees.

Keeping Software Updated

Keeping your Dataverse software updated is crucial for preventing vulnerabilities. Regular updates ensure that you benefit from the latest security features and patches. Here are some strategies to maintain up-to-date software:

Implement Data Loss Prevention (DLP) Policies to control data flow and prevent risks.
Enforce Encryption and Secure Network Access to protect data in transit.
Use Role-Based Data Permissions to limit access based on necessity.
Audit and Monitor Sensitive Access to track data usage and permissions.
Automate User and App Lifecycle to manage access efficiently.
Conduct Regular Security Reviews and Compliance Checks to identify and mitigate risks.

By following these best practices, you can enhance your organization's security model and protect sensitive data effectively. Prioritizing security not only safeguards your data but also builds trust with your users and stakeholders.

Common Security Threats in Dataverse

Phishing Attacks

Phishing attacks pose a significant threat to your Dataverse environment. Attackers often use deceptive emails or messages to trick you into revealing sensitive information. These attacks can lead to unauthorized access and data breaches. To combat phishing, you should implement several strategies:

Strategy	Description
Multifactor Authentication (MFA)	Enforces MFA to prevent unauthorized access, mitigating phishing attempts that mimic authentication interfaces.
Least-Privileged Access	Limits access to data and actions based on user roles, closing gaps that attackers exploit after phishing.
End-to-End Encryption	Encrypts data at rest and in transit, preventing attackers from leveraging stolen credentials for broader exploitation.
Secure Deployment	Implements application lifecycle security to block unauthorized modifications post-phishing.
Continuous Security Audits	Regularly audits permissions and access to detect and mitigate potential phishing vulnerabilities.

By adopting these measures, you can significantly reduce the risk of falling victim to phishing attacks.

Data Breaches

Data breaches represent another critical threat to your organization. These incidents occur when unauthorized individuals gain access to sensitive data. The consequences can be severe, including financial loss and reputational damage. Common causes of data breaches include weak passwords, unpatched software, and insider threats.

To mitigate the risk of data breaches, consider the following:

Regularly update your software to patch vulnerabilities.
Use strong, unique passwords for all accounts.
Monitor user activity for unusual behavior.
Implement Data Loss Prevention (DLP) policies to control data sharing.

The table below highlights some prevalent security threats targeting Dataverse users:

Security Threat Description	Type of Threat
Unusual sign-ins following disabled IP address-based cookie binding protection	Defense Evasion
User bulk retrieval outside normal activity	Exfiltration
Suspicious security role modifications	Privilege Escalation
Suspicious use of TDS endpoint	Exfiltration, Initial Access
Terminated employee exfiltration over email	Exfiltration
Terminated employee exfiltration to USB drive	Exfiltration
Executable uploaded to SharePoint document management site	Execution, Persistence
Mass deletion of records	Impact
Mass download from SharePoint document management	Exfiltration

Insider Threats

Insider threats can be just as damaging as external attacks. These threats arise from employees or contractors who misuse their access to sensitive data. To prevent insider threats, you should focus on the following measures:

Staff training and awareness
Proactive protection measures
Implementation of security systems

By fostering a culture of security awareness and implementing robust security measures, you can protect your organization from insider threats.

Future of Dataverse Security

Emerging Technologies

As you look ahead, emerging technologies will shape the future of Dataverse security. These advancements will enhance your ability to protect sensitive data and manage user access effectively. Here are some key technologies to watch:

Automated Data Discovery: This technology will help you identify and classify sensitive data across your environments. It will enable you to understand your data estate better and enhance your compliance posture.
Data Masking: You will be able to create data masking rules to protect personally identifiable information (PII). This process replaces sensitive data with masked strings, ensuring that only authorized users can access the original values.
Enhanced Collaboration Tools: Future developments will emphasize collaboration between security teams and application developers. This collaboration will lead to more robust security controls and streamlined processes.

These technologies will not only improve security but also simplify compliance with regulations like GDPR and HIPAA.

Trends in Data Protection

The landscape of data protection is evolving rapidly. You should stay informed about the latest trends that will impact your Dataverse security practices:

Role-Based Access Control: This approach will continue to be vital for managing data visibility and editing permissions. It ensures that users only access the data necessary for their roles.
Field-Level Security: Protecting sensitive information will remain a priority. Field-level security will restrict access to specific data fields, safeguarding critical information from unauthorized users.
Auditing Capabilities: Enhanced auditing features will track user activity and data changes. This capability will help you ensure compliance with regulations and respond quickly to potential security incidents.
Data Encryption: Encrypting data during transit and at rest will maintain confidentiality and security. This practice will be essential as cyber threats become more sophisticated.

By embracing these trends, you can strengthen your organization's data protection strategies and enhance your overall security posture.

In summary, understanding Dataverse security is essential for protecting your organization's data. You can implement various security features, such as security roles, access levels, and field-level security, to safeguard sensitive information. Regular audits, user training, and keeping software updated further enhance your security posture. By prioritizing these practices, you empower your organization to operate securely and efficiently in today's digital landscape. Remember, a strong security framework not only protects data but also builds trust with your users. 🌟

FAQ

What is Dataverse Security?

Dataverse Security refers to the measures and features that protect data within Microsoft Dataverse. It includes security roles, access levels, and field-level security to ensure data integrity and user privacy.

Why is security important in Dataverse?

Security in Dataverse is crucial to protect sensitive information, prevent unauthorized access, and ensure compliance with regulations. It helps maintain trust and integrity within your organization.

How do security roles work in Dataverse?

Security roles define user permissions for accessing and manipulating data. You can assign built-in or custom roles to users, ensuring they only access data relevant to their job functions.

What is field-level security?

Field-level security allows you to restrict access to specific fields within records. This feature protects sensitive information, ensuring only authorized users can view or modify critical data.

How can I conduct security audits in Dataverse?

You can conduct security audits by regularly reviewing user permissions, monitoring access logs, and using automated tools. This process helps identify vulnerabilities and ensures compliance with security policies.

What are common threats to Dataverse security?

Common threats include phishing attacks, data breaches, and insider threats. Implementing strong security measures, such as user training and regular audits, can help mitigate these risks.

How can I improve user awareness of security?

You can improve user awareness by providing training on security policies, recognizing phishing attempts, and best practices for password management. Regular refreshers keep security top of mind for employees.

What should I do if I suspect a data breach?

If you suspect a data breach, immediately report it to your security team. Investigate the incident, assess the damage, and take steps to secure your data and prevent future breaches.

🎧 Listen to this episode

Want a practical explanation of Dataverse Security? This episode breaks down the topic in clear language and shows why it matters for Microsoft 365, Azure, Power Platform, security, AI, and modern work.

Listen to this episode if you want to:

Understand the key concepts behind Dataverse Security
See how it fits into the wider Microsoft technology ecosystem
Learn where it can create practical value for your organization

You may also enjoy these related M365 FM episodes:

Discover more practical Microsoft conversations on M365 FM.

🚀 Want to be part of m365.fm?

Then stop just listening… and start showing up.

👉 Connect with me on LinkedIn and let’s make something happen:

🎙️ Be a podcast guest and share your story
🎧 Host your own episode (yes, seriously)
💡 Pitch topics the community actually wants to hear
🌍 Build your personal brand in the Microsoft 365 space

This isn’t just a podcast — it’s a platform for people who take action.

🔥 Most people wait. The best ones don’t.

👉 Connect with me on LinkedIn and send me a message:
"I want in"

Let’s build something awesome 👊

1
00:00:00,000 --> 00:00:02,520
So today's topic is one that almost everyone has heard of,

2
00:00:02,520 --> 00:00:05,400
but very few people actually understand security in data

3
00:00:05,400 --> 00:00:06,320
verse.

4
00:00:06,320 --> 00:00:09,520
Most people hear security and think passwords, licenses,

5
00:00:09,520 --> 00:00:12,040
or who can open an app and sure those things matter.

6
00:00:12,040 --> 00:00:14,680
But data verse security goes much deeper than that.

7
00:00:14,680 --> 00:00:16,440
Here's the simplest way to think about it.

8
00:00:16,440 --> 00:00:19,040
Data verse has three distinct layers of access control

9
00:00:19,040 --> 00:00:20,520
stacked on top of each other.

10
00:00:20,520 --> 00:00:23,240
The table level controls what actions someone can perform,

11
00:00:23,240 --> 00:00:25,640
the row level controls, which records they can actually

12
00:00:25,640 --> 00:00:28,360
see, and the column level protects individual fields

13
00:00:28,360 --> 00:00:29,240
within a record.

14
00:00:29,240 --> 00:00:30,800
By the end of this episode, you'll

15
00:00:30,800 --> 00:00:33,480
understand how these layers work together and why each one

16
00:00:33,480 --> 00:00:35,400
matters for keeping your data safe.

17
00:00:35,400 --> 00:00:38,080
Grab your coffee and let's break it down from the ground up.

18
00:00:38,080 --> 00:00:40,520
Security roles, who can do what on tables?

19
00:00:40,520 --> 00:00:43,360
Let's start with the most fundamental layer security roles.

20
00:00:43,360 --> 00:00:46,520
A security role defines the actions a user can perform

21
00:00:46,520 --> 00:00:50,760
on a specific table, create, read, write, delete, append,

22
00:00:50,760 --> 00:00:52,000
assign, share.

23
00:00:52,000 --> 00:00:53,920
Those are the basic building blocks of access.

24
00:00:53,920 --> 00:00:55,240
Think of it like a building pass.

25
00:00:55,240 --> 00:00:57,520
Some people get a pass that only lets them into the lobby.

26
00:00:57,520 --> 00:01:00,080
They can look around but can't enter any offices.

27
00:01:00,080 --> 00:01:01,320
And that's read only access.

28
00:01:01,320 --> 00:01:03,960
Other people get a pass that lets them into offices

29
00:01:03,960 --> 00:01:05,480
so they can write to records.

30
00:01:05,480 --> 00:01:07,200
And a few people get a pass that lets them

31
00:01:07,200 --> 00:01:09,280
remodel the whole floor, meaning they can

32
00:01:09,280 --> 00:01:11,120
delete and reassign permissions.

33
00:01:11,120 --> 00:01:14,520
Now security roles are assigned to users or teams inside

34
00:01:14,520 --> 00:01:16,000
a data verse environment.

35
00:01:16,000 --> 00:01:17,080
And here's the key point.

36
00:01:17,080 --> 00:01:19,280
Every single user needs at least one security role

37
00:01:19,280 --> 00:01:20,560
to do anything at all.

38
00:01:20,560 --> 00:01:22,200
No role means no access.

39
00:01:22,200 --> 00:01:24,040
The system simply won't let them in.

40
00:01:24,040 --> 00:01:26,760
Microsoft provides a set of pre-built roles to get you started.

41
00:01:26,760 --> 00:01:28,800
You've got basic user, the minimum for anyone

42
00:01:28,800 --> 00:01:31,960
who needs to interact with the system, system customizer,

43
00:01:31,960 --> 00:01:33,760
which lets people customize the environment,

44
00:01:33,760 --> 00:01:35,440
but not change security.

45
00:01:35,440 --> 00:01:38,600
System administrator, which is full access to everything,

46
00:01:38,600 --> 00:01:41,800
an environment maker, which lets people create resources

47
00:01:41,800 --> 00:01:44,480
but grants zero data access on its own.

48
00:01:44,480 --> 00:01:45,840
Each one comes with different defaults.

49
00:01:45,840 --> 00:01:47,960
Now this is where custom roles really shine.

50
00:01:47,960 --> 00:01:49,440
You don't have to build one from scratch,

51
00:01:49,440 --> 00:01:51,400
instead copy basic user as a starting point

52
00:01:51,400 --> 00:01:53,760
and tweak the permissions for your own custom tables.

53
00:01:53,760 --> 00:01:56,400
That way you keep all the default access users need

54
00:01:56,400 --> 00:01:59,520
while adding only the specific permissions your scenario requires.

55
00:01:59,520 --> 00:02:01,520
Once you know what actions a role allows,

56
00:02:01,520 --> 00:02:05,040
the next question is which specific rows can they see?

57
00:02:05,040 --> 00:02:07,520
That's where access levels come in.

58
00:02:07,520 --> 00:02:09,760
Access levels, the scope of that permission.

59
00:02:09,760 --> 00:02:12,280
A security role doesn't just say you can read.

60
00:02:12,280 --> 00:02:14,600
It says you can read this much of the data.

61
00:02:14,600 --> 00:02:16,640
That range is called the access level

62
00:02:16,640 --> 00:02:19,280
and it decides how far your view goes across the system.

63
00:02:19,280 --> 00:02:20,920
There are four main access levels.

64
00:02:20,920 --> 00:02:21,840
First is user.

65
00:02:21,840 --> 00:02:23,960
You only see records your own, then business unit

66
00:02:23,960 --> 00:02:26,240
where you see records from anyone in your department,

67
00:02:26,240 --> 00:02:27,680
parent child business units,

68
00:02:27,680 --> 00:02:30,440
extend that to include any sub-departments underneath yours.

69
00:02:30,440 --> 00:02:32,960
And finally, organization which gives you a full view

70
00:02:32,960 --> 00:02:35,040
of every record in the whole environment.

71
00:02:35,040 --> 00:02:36,640
Let me give you a concrete example.

72
00:02:36,640 --> 00:02:40,320
A sales rep might have read, user on the opportunities table.

73
00:02:40,320 --> 00:02:42,720
That means they only see their own deals,

74
00:02:42,720 --> 00:02:44,400
not their co-workers pipeline.

75
00:02:44,400 --> 00:02:48,680
A sales manager though might get read business unit.

76
00:02:48,680 --> 00:02:50,560
That lets them see the whole team's opportunities

77
00:02:50,560 --> 00:02:52,840
because they need that visibility to manage performance.

78
00:02:52,840 --> 00:02:55,320
Now here's something that trips up new admins all the time.

79
00:02:55,320 --> 00:02:56,600
Privileges are additive.

80
00:02:56,600 --> 00:02:58,840
If a user has two different security roles,

81
00:02:58,840 --> 00:03:00,520
the system doesn't average them out.

82
00:03:00,520 --> 00:03:03,120
It takes the least restrictive permission for each action.

83
00:03:03,120 --> 00:03:05,400
So if one role says read, user,

84
00:03:05,400 --> 00:03:08,120
and the other says read, organization,

85
00:03:08,120 --> 00:03:10,720
the user gets read, organization.

86
00:03:10,720 --> 00:03:12,360
The broader permission always wins.

87
00:03:12,360 --> 00:03:13,360
And here's the gotcha.

88
00:03:13,360 --> 00:03:14,760
Because permission stack up,

89
00:03:14,760 --> 00:03:17,400
you can't subtract access by adding another role.

90
00:03:17,400 --> 00:03:18,720
You only get more access.

91
00:03:18,720 --> 00:03:20,200
If you need to restrict someone,

92
00:03:20,200 --> 00:03:22,200
you have to remove the role giving them too much

93
00:03:22,200 --> 00:03:24,000
or use a different mechanism entirely.

94
00:03:24,000 --> 00:03:25,920
That mistake causes a lot of head scratching.

95
00:03:25,920 --> 00:03:27,600
So security roles control what you can do

96
00:03:27,600 --> 00:03:28,960
and how wide your view is.

97
00:03:28,960 --> 00:03:31,640
But the real data segmentation happens next

98
00:03:31,640 --> 00:03:33,280
with business units and teams.

99
00:03:33,280 --> 00:03:35,640
Business units, your organizational structure.

100
00:03:35,640 --> 00:03:37,520
We've covered what actions a user can take

101
00:03:37,520 --> 00:03:38,720
and how wide their view is.

102
00:03:38,720 --> 00:03:41,440
But in a real company, you don't want everyone seeing everything.

103
00:03:41,440 --> 00:03:43,000
That's where business units come in.

104
00:03:43,000 --> 00:03:45,160
Business units are basically your departments

105
00:03:45,160 --> 00:03:48,200
or divisions, sales, marketing, finance, support.

106
00:03:48,200 --> 00:03:51,040
They create a hierarchy that mirrors your actual org chart.

107
00:03:51,040 --> 00:03:53,280
And they're the main way to segment data in data verse.

108
00:03:53,280 --> 00:03:54,560
Here's how it works.

109
00:03:54,560 --> 00:03:57,480
Every user belongs to exactly one default business unit

110
00:03:57,480 --> 00:04:00,280
and records can own a business unit too.

111
00:04:00,280 --> 00:04:01,920
When a sales rep creates a new account,

112
00:04:01,920 --> 00:04:04,240
that record belongs to the sales business unit.

113
00:04:04,240 --> 00:04:06,240
This connection between user business unit

114
00:04:06,240 --> 00:04:09,480
and the records they create is the foundation of role level access.

115
00:04:09,480 --> 00:04:12,120
The classic model for business units was pretty strict.

116
00:04:12,120 --> 00:04:14,120
Users could only see records within their own unit

117
00:04:14,120 --> 00:04:15,720
in any child units beneath it.

118
00:04:15,720 --> 00:04:17,640
If you were in sales, you saw sales records,

119
00:04:17,640 --> 00:04:19,160
marketing, soul marketing records.

120
00:04:19,160 --> 00:04:20,760
Those two worlds never crossed.

121
00:04:20,760 --> 00:04:23,240
That worked fine for organizations with strict silos

122
00:04:23,240 --> 00:04:25,800
where departments operated completely independently.

123
00:04:25,800 --> 00:04:27,880
But the modernized model is much more flexible.

124
00:04:27,880 --> 00:04:29,120
Microsoft introduced something called

125
00:04:29,120 --> 00:04:31,120
a matrix data access structure.

126
00:04:31,120 --> 00:04:33,360
Instead of locking users into one business unit,

127
00:04:33,360 --> 00:04:35,880
you can assign security roles from multiple business units

128
00:04:35,880 --> 00:04:36,840
to a single user.

129
00:04:36,840 --> 00:04:39,200
So a user can access records across different units,

130
00:04:39,200 --> 00:04:41,680
even if they're not assigned to those units themselves.

131
00:04:41,680 --> 00:04:43,480
This is a big deal for cross-functional work.

132
00:04:43,480 --> 00:04:45,200
Imagine a marketing person in the US

133
00:04:45,200 --> 00:04:48,040
who needs to see campaign data from the European office.

134
00:04:48,040 --> 00:04:50,360
In the classic model, you'd have to jump through hoops

135
00:04:50,360 --> 00:04:51,240
to make that happen.

136
00:04:51,240 --> 00:04:54,360
In the modernized model, you just give them a security role

137
00:04:54,360 --> 00:04:56,960
from the European business unit with the right permissions.

138
00:04:56,960 --> 00:04:57,800
Simple.

139
00:04:57,800 --> 00:04:59,360
The owning business unit column on each record

140
00:04:59,360 --> 00:05:00,600
makes this possible.

141
00:05:00,600 --> 00:05:03,840
That column determines which business unit owns the record.

142
00:05:03,840 --> 00:05:05,840
Access is granted based on the security roles

143
00:05:05,840 --> 00:05:07,760
assigned from that business unit, regardless

144
00:05:07,760 --> 00:05:08,840
of where the user sits.

145
00:05:08,840 --> 00:05:11,320
The user's own business unit becomes less relevant.

146
00:05:11,320 --> 00:05:13,080
What matters is what roles they have and where

147
00:05:13,080 --> 00:05:14,320
those roles come from.

148
00:05:14,320 --> 00:05:16,680
You create business units through the power platform

149
00:05:16,680 --> 00:05:17,800
admin center.

150
00:05:17,800 --> 00:05:19,520
Set up a parent and child structure,

151
00:05:19,520 --> 00:05:21,800
head office at the top departments underneath,

152
00:05:21,800 --> 00:05:23,720
then assign users to the right unit.

153
00:05:23,720 --> 00:05:25,360
It takes a few minutes to configure,

154
00:05:25,360 --> 00:05:27,480
but it's one of those things you want to get right from the start

155
00:05:27,480 --> 00:05:29,920
because restructuring later is painful.

156
00:05:29,920 --> 00:05:31,600
But business units alone aren't enough.

157
00:05:31,600 --> 00:05:33,760
You also need teams to handle group ownership

158
00:05:33,760 --> 00:05:36,440
and shared access efficiently.

159
00:05:36,440 --> 00:05:37,160
Teams.

160
00:05:37,160 --> 00:05:38,680
Owning records as a group.

161
00:05:38,680 --> 00:05:41,040
Teams let groups of people own records together.

162
00:05:41,040 --> 00:05:44,560
Two main types matter here, owning teams and access teams.

163
00:05:44,560 --> 00:05:47,320
An owning team holds record ownership as a group.

164
00:05:47,320 --> 00:05:48,960
Imagine a sales team with five people.

165
00:05:48,960 --> 00:05:50,520
That team owns one account record.

166
00:05:50,520 --> 00:05:54,080
Any member can work on it, update it, assign tasks from it.

167
00:05:54,080 --> 00:05:55,640
The record doesn't belong to one person.

168
00:05:55,640 --> 00:05:56,760
It belongs to the whole group.

169
00:05:56,760 --> 00:05:59,040
That's perfect when multiple people need ongoing access

170
00:05:59,040 --> 00:06:00,400
to the same set of records.

171
00:06:00,400 --> 00:06:01,720
Access teams work differently.

172
00:06:01,720 --> 00:06:02,640
They don't own records.

173
00:06:02,640 --> 00:06:04,600
Instead, they're built for sharing specific records

174
00:06:04,600 --> 00:06:06,120
without changing ownership.

175
00:06:06,120 --> 00:06:08,200
Say, a support agent needs temporary access

176
00:06:08,200 --> 00:06:09,920
to a sales account to resolve a ticket.

177
00:06:09,920 --> 00:06:11,520
You add that account to an access team

178
00:06:11,520 --> 00:06:14,240
and the agent gets access without the record changing hands.

179
00:06:14,240 --> 00:06:15,760
Great for ad hoc collaboration.

180
00:06:15,760 --> 00:06:16,960
Now here's where it gets powerful.

181
00:06:16,960 --> 00:06:17,760
Group teams.

182
00:06:17,760 --> 00:06:20,520
You can link a team directly to a Microsoft EntraID Security

183
00:06:20,520 --> 00:06:21,000
group.

184
00:06:21,000 --> 00:06:23,200
When you do that, memberships things automatically.

185
00:06:23,200 --> 00:06:24,920
Add someone to the security group in Entra

186
00:06:24,920 --> 00:06:26,720
and they appear in the Dataverse team.

187
00:06:26,720 --> 00:06:28,800
Remove them from the group and they're gone from the team.

188
00:06:28,800 --> 00:06:30,200
No manual updates needed.

189
00:06:30,200 --> 00:06:33,360
That means you don't have to add users one by one in Dataverse.

190
00:06:33,360 --> 00:06:35,080
Just manage your groups in EntraID

191
00:06:35,080 --> 00:06:36,640
and the team updates itself.

192
00:06:36,640 --> 00:06:39,000
For large organizations, this saves a ton of time.

193
00:06:39,000 --> 00:06:41,080
You can manage thousands of users

194
00:06:41,080 --> 00:06:42,760
through a handful of security groups

195
00:06:42,760 --> 00:06:45,120
instead of clicking through admin screens all day.

196
00:06:45,120 --> 00:06:46,040
And here's the clean part.

197
00:06:46,040 --> 00:06:48,200
When you assign a security role to a team,

198
00:06:48,200 --> 00:06:50,320
every single member inherits those permissions.

199
00:06:50,320 --> 00:06:52,720
You don't assign the role to each person individually.

200
00:06:52,720 --> 00:06:55,760
You assign it once to the team and it applies to everyone.

201
00:06:55,760 --> 00:06:57,640
That's scalable, consistent and easy to audit.

202
00:06:57,640 --> 00:07:00,720
So now we've got roles controlling what actions users can take,

203
00:07:00,720 --> 00:07:03,080
business units, scoping which rows they can see

204
00:07:03,080 --> 00:07:05,000
and teams handling group access.

205
00:07:05,000 --> 00:07:07,320
But what about the most granular layer of all?

206
00:07:07,320 --> 00:07:09,120
Individual columns within a record.

207
00:07:09,120 --> 00:07:11,600
That's where field level security comes in.

208
00:07:11,600 --> 00:07:14,440
Field level security, hiding specific columns.

209
00:07:14,440 --> 00:07:17,080
So roles control what actions users can take.

210
00:07:17,080 --> 00:07:19,840
Business units and teams scope which rows they can see.

211
00:07:19,840 --> 00:07:21,760
But what if the problem isn't a whole record?

212
00:07:21,760 --> 00:07:23,120
What if you need to restrict access

213
00:07:23,120 --> 00:07:25,680
to just one single column inside a record?

214
00:07:25,680 --> 00:07:28,040
Think about a salary field on an employee record

215
00:07:28,040 --> 00:07:30,000
or a social security number on a contact

216
00:07:30,000 --> 00:07:31,760
or a credit card number on an account.

217
00:07:31,760 --> 00:07:33,680
You don't want to hide the entire record.

218
00:07:33,680 --> 00:07:35,680
The sales rep still needs to see the customers name

219
00:07:35,680 --> 00:07:36,600
and phone number.

220
00:07:36,600 --> 00:07:39,000
But that one field that needs to be locked down tight,

221
00:07:39,000 --> 00:07:42,400
field level security or FLS handles exactly the scenario.

222
00:07:42,400 --> 00:07:43,440
Here's how it works.

223
00:07:43,440 --> 00:07:45,680
You mark a specific column as secured.

224
00:07:45,680 --> 00:07:48,400
Then you create something called a field security profile.

225
00:07:48,400 --> 00:07:50,400
That profile defines which users or teams

226
00:07:50,400 --> 00:07:51,960
get access to that secured field.

227
00:07:51,960 --> 00:07:53,240
Only those people can see it.

228
00:07:53,240 --> 00:07:54,560
Here's how strict this really is.

229
00:07:54,560 --> 00:07:57,280
Without a field security profile, nobody can see that column.

230
00:07:57,280 --> 00:07:59,320
Not even a system administrator who owns the record.

231
00:07:59,320 --> 00:08:00,440
It's completely hidden.

232
00:08:00,440 --> 00:08:02,560
Or depending on how you configure it, masked.

233
00:08:02,560 --> 00:08:04,280
The field simply doesn't show up for anyone

234
00:08:04,280 --> 00:08:07,200
who isn't explicitly granted access through a profile.

235
00:08:07,200 --> 00:08:08,640
And this part surprises people.

236
00:08:08,640 --> 00:08:10,480
FLS overrides table level permissions.

237
00:08:10,480 --> 00:08:11,640
Let me say that again.

238
00:08:11,640 --> 00:08:13,480
The user might have read organization access

239
00:08:13,480 --> 00:08:14,800
on the contacts table.

240
00:08:14,800 --> 00:08:16,320
They can see every single contact record

241
00:08:16,320 --> 00:08:17,400
in the entire environment.

242
00:08:17,400 --> 00:08:20,120
But if the tax ID column on that table is secured

243
00:08:20,120 --> 00:08:21,720
and they don't have a profile for it,

244
00:08:21,720 --> 00:08:22,960
that column is blank.

245
00:08:22,960 --> 00:08:24,960
Table level permission doesn't help them.

246
00:08:24,960 --> 00:08:27,040
FLS sits on top and says no.

247
00:08:27,040 --> 00:08:29,680
Profiles themselves have three permissions you can grant.

248
00:08:29,680 --> 00:08:31,640
Read, update, and create.

249
00:08:31,640 --> 00:08:34,160
So you can let someone read a field but not change it.

250
00:08:34,160 --> 00:08:36,400
Or allow them to create records with that field,

251
00:08:36,400 --> 00:08:38,960
populate it but not edit existing values.

252
00:08:38,960 --> 00:08:40,960
Or give full access to a specific team

253
00:08:40,960 --> 00:08:42,400
while keeping everyone else out.

254
00:08:42,400 --> 00:08:44,080
That's granular control at the column level.

255
00:08:44,080 --> 00:08:46,080
FLS is powerful but you don't want to throw it

256
00:08:46,080 --> 00:08:47,560
at every column in your database.

257
00:08:47,560 --> 00:08:49,600
And there are limits and performance considerations

258
00:08:49,600 --> 00:08:50,920
you need to know about.

259
00:08:50,920 --> 00:08:53,840
FLS limits, masking, and best practices.

260
00:08:53,840 --> 00:08:55,800
So how many fields can you actually lock down

261
00:08:55,800 --> 00:08:57,240
with field level security?

262
00:08:57,240 --> 00:08:58,880
The answer is a few dozen, not hundreds.

263
00:08:58,880 --> 00:09:01,240
You can't secure every single column in a table.

264
00:09:01,240 --> 00:09:02,560
And honestly, you wouldn't want to.

265
00:09:02,560 --> 00:09:03,360
Here's why.

266
00:09:03,360 --> 00:09:06,040
Every secured field adds overhead to every query.

267
00:09:06,040 --> 00:09:08,640
The system checks user memberships, evaluates permissions

268
00:09:08,640 --> 00:09:10,400
and strips out hidden fields.

269
00:09:10,400 --> 00:09:13,200
Do that for one or two fields and the performance hit is tiny.

270
00:09:13,200 --> 00:09:15,040
Do it for 30 fields on a busy table

271
00:09:15,040 --> 00:09:16,920
and your apps start to feel sluggish.

272
00:09:16,920 --> 00:09:19,320
Use FLS sparingly.

273
00:09:19,320 --> 00:09:22,200
Now there's a feature that arrived around 2025

274
00:09:22,200 --> 00:09:23,320
that I really like.

275
00:09:23,320 --> 00:09:24,280
Column masking.

276
00:09:24,280 --> 00:09:25,880
Instead of hiding a field completely,

277
00:09:25,880 --> 00:09:27,800
you show part of it using regular expressions.

278
00:09:27,800 --> 00:09:30,040
For example, a customer support agent

279
00:09:30,040 --> 00:09:31,560
might see only the last four digits

280
00:09:31,560 --> 00:09:32,720
of a credit card number.

281
00:09:32,720 --> 00:09:33,720
The rest is masked.

282
00:09:33,720 --> 00:09:36,520
They can verify the card without ever seeing the full number.

283
00:09:36,520 --> 00:09:38,080
The masking is applied server side

284
00:09:38,080 --> 00:09:41,640
so it works consistently across forms, reports and API responses.

285
00:09:41,640 --> 00:09:44,400
There's also app access control, which lets you restrict

286
00:09:44,400 --> 00:09:47,000
which applications can interact with secured fields.

287
00:09:47,000 --> 00:09:50,240
You can block Excel desktop from reading sensitive data, for example.

288
00:09:50,240 --> 00:09:51,880
It's another layer of defense against someone

289
00:09:51,880 --> 00:09:53,920
trying to export data through a back door.

290
00:09:53,920 --> 00:09:56,000
And here's something that matters for mobile users.

291
00:09:56,000 --> 00:09:57,960
Offline caches respect FLS.

292
00:09:57,960 --> 00:09:59,800
When a user downloads data to their laptop

293
00:09:59,800 --> 00:10:01,200
or phone for offline use,

294
00:10:01,200 --> 00:10:03,040
secured fields don't come along.

295
00:10:03,040 --> 00:10:04,880
Sensitive data stays on the server.

296
00:10:04,880 --> 00:10:07,200
That's important for compliance with regulations

297
00:10:07,200 --> 00:10:08,720
like GDPR and HIPAA.

298
00:10:08,720 --> 00:10:10,080
So what's the best practice?

299
00:10:10,080 --> 00:10:11,520
Start with table level roles.

300
00:10:11,520 --> 00:10:13,040
That's your first line of defense,

301
00:10:13,040 --> 00:10:15,200
then add business units for row segmentation.

302
00:10:15,200 --> 00:10:16,240
That's your second layer.

303
00:10:16,240 --> 00:10:19,320
Only then use FLS for truly sensitive columns.

304
00:10:19,320 --> 00:10:22,360
Salary, tax ID, credit card numbers.

305
00:10:22,360 --> 00:10:24,640
Don't stack layers unless you actually need them.

306
00:10:24,640 --> 00:10:26,840
Every layer adds complexity and complexity

307
00:10:26,840 --> 00:10:28,680
is the enemy of a clean security model.

308
00:10:28,680 --> 00:10:30,440
So now you have the full picture.

309
00:10:30,440 --> 00:10:31,800
Three layers working together.

310
00:10:31,800 --> 00:10:33,080
But how do you actually troubleshoot

311
00:10:33,080 --> 00:10:35,280
when someone can't see what they should?

312
00:10:35,280 --> 00:10:37,000
Common pitfalls and troubleshooting.

313
00:10:37,000 --> 00:10:39,040
So let's talk about the things that actually go wrong.

314
00:10:39,040 --> 00:10:40,800
Because knowing the theory is one thing,

315
00:10:40,800 --> 00:10:44,080
but knowing where people trip up saves you hours of frustration.

316
00:10:44,080 --> 00:10:45,520
The most common mistake I see is this.

317
00:10:45,520 --> 00:10:47,240
Someone creates a custom security role,

318
00:10:47,240 --> 00:10:48,480
assigns it to a user,

319
00:10:48,480 --> 00:10:51,760
and then wonders why that user can't log into data verse at all.

320
00:10:51,760 --> 00:10:53,600
The answer is almost always the same.

321
00:10:53,600 --> 00:10:56,560
They forgot to also assign the basic user role.

322
00:10:56,560 --> 00:10:58,480
Basic user is the minimum set of permissions

323
00:10:58,480 --> 00:11:00,720
that let someone interact with the environment.

324
00:11:00,720 --> 00:11:02,920
Without it, your fancy custom role doesn't matter.

325
00:11:02,920 --> 00:11:05,480
The user can't even get through the door.

326
00:11:05,480 --> 00:11:06,640
Another one that catches people.

327
00:11:06,640 --> 00:11:08,040
You give a user too much access.

328
00:11:08,040 --> 00:11:10,800
So you assign them another role that you think will restrict them,

329
00:11:10,800 --> 00:11:11,760
but it doesn't work.

330
00:11:11,760 --> 00:11:13,920
Because permissions are additive, not subtractive.

331
00:11:13,920 --> 00:11:17,040
You can't use one role to take away what another role grants.

332
00:11:17,040 --> 00:11:18,720
The system always picks the broadest permission.

333
00:11:18,720 --> 00:11:20,280
If you need to restrict someone,

334
00:11:20,280 --> 00:11:22,880
you have to remove the over permissive role entirely,

335
00:11:22,880 --> 00:11:26,080
or use field-level security to lock down specific columns.

336
00:11:26,080 --> 00:11:27,240
There's no middle ground.

337
00:11:27,240 --> 00:11:29,400
Business unit misalignment is another classic.

338
00:11:29,400 --> 00:11:31,520
A user belongs to the sales business unit,

339
00:11:31,520 --> 00:11:32,960
but the record they need to see

340
00:11:32,960 --> 00:11:35,000
has an owning business unit of marketing.

341
00:11:35,000 --> 00:11:36,760
Even if they have read organization on that table,

342
00:11:36,760 --> 00:11:38,760
they might not see it in their default views.

343
00:11:38,760 --> 00:11:40,840
The record exists and the permission is technically there,

344
00:11:40,840 --> 00:11:42,400
but the view is filtered by business unit

345
00:11:42,400 --> 00:11:43,840
and nobody thinks to check that.

346
00:11:43,840 --> 00:11:45,640
Team ownership confuses people too.

347
00:11:45,640 --> 00:11:48,720
If a team owns a record, individual ownership doesn't apply.

348
00:11:48,720 --> 00:11:50,480
Only team members can modify it,

349
00:11:50,480 --> 00:11:53,400
unless a user has a higher access level like organization.

350
00:11:53,400 --> 00:11:56,600
So if someone says, "I can see the record, but I can't edit it,"

351
00:11:56,600 --> 00:11:57,920
check who owns it first.

352
00:11:57,920 --> 00:11:59,880
If it's a team, they need to be on that team.

353
00:11:59,880 --> 00:12:02,160
And here's the one that took me an hour to find once.

354
00:12:02,160 --> 00:12:04,440
A user complains they can't see a field.

355
00:12:04,440 --> 00:12:07,520
You check their security role, full read on the table.

356
00:12:07,520 --> 00:12:09,920
You check the access level, organization.

357
00:12:09,920 --> 00:12:12,240
Everything looks fine, but the field is blank.

358
00:12:12,240 --> 00:12:13,640
You dig deeper and there it is.

359
00:12:13,640 --> 00:12:15,600
The field is secured with FLS.

360
00:12:15,600 --> 00:12:17,200
The user has table level access,

361
00:12:17,200 --> 00:12:18,640
but no field security profile,

362
00:12:18,640 --> 00:12:20,480
so the field is simply invisible to them.

363
00:12:20,480 --> 00:12:22,880
That one is easy to miss because the table level permission

364
00:12:22,880 --> 00:12:23,920
looks correct.

365
00:12:23,920 --> 00:12:26,720
These gotchas are easy to avoid once you know the patterns.

366
00:12:26,720 --> 00:12:30,320
Let's wrap up with how all three layers fit together in practice.

367
00:12:30,320 --> 00:12:31,880
The three layers working together.

368
00:12:31,880 --> 00:12:33,360
So here's how it all fits together.

369
00:12:33,360 --> 00:12:36,040
Security roles control what you can do on a table.

370
00:12:36,040 --> 00:12:38,240
Create, read, update, delete.

371
00:12:38,240 --> 00:12:40,960
Business units and teams decide which rows you can see.

372
00:12:40,960 --> 00:12:43,200
And field level security protects individual columns

373
00:12:43,200 --> 00:12:44,360
from prying eyes.

374
00:12:44,360 --> 00:12:46,280
Three layers and you really need all of them

375
00:12:46,280 --> 00:12:47,880
for a complete security model.

376
00:12:47,880 --> 00:12:50,600
Think of it like a physical building with three checkpoints.

377
00:12:50,600 --> 00:12:52,040
First, your badge lets you in the door.

378
00:12:52,040 --> 00:12:53,240
That's your security role.

379
00:12:53,240 --> 00:12:55,200
Second, you can only walk into your own department.

380
00:12:55,200 --> 00:12:56,280
That's your business unit.

381
00:12:56,280 --> 00:12:58,200
Third, certain filing cabinets are locked

382
00:12:58,200 --> 00:12:59,880
and only certain people can open them.

383
00:12:59,880 --> 00:13:01,120
That's field level security.

384
00:13:01,120 --> 00:13:03,080
Each layer builds on the one before it.

385
00:13:03,080 --> 00:13:04,440
Your next step is simple.

386
00:13:04,440 --> 00:13:05,640
Open your own environment.

387
00:13:05,640 --> 00:13:08,280
Find a table that might need row or column restrictions.

388
00:13:08,280 --> 00:13:10,840
Start small, duplicate the basic user role,

389
00:13:10,840 --> 00:13:13,320
create a test team, add one secured field,

390
00:13:13,320 --> 00:13:14,600
watch how the layers interact,

391
00:13:14,600 --> 00:13:17,040
nothing teaches faster than doing it yourself.

392
00:13:17,040 --> 00:13:18,960
Subscribe on your favorite podcast platform

393
00:13:18,960 --> 00:13:20,280
and share this episode with someone

394
00:13:20,280 --> 00:13:21,960
starting their database journey.

Mirko Peters

Founder of m365.fm, m365.show and m365con.net

Mirko Peters is a Microsoft 365 expert, content creator, and founder of m365.fm, a platform dedicated to sharing practical insights on modern workplace technologies. His work focuses on Microsoft 365 governance, security, collaboration, and real-world implementation strategies.

Through his podcast and written content, Mirko provides hands-on guidance for IT professionals, architects, and business leaders navigating the complexities of Microsoft 365. He is known for translating complex topics into clear, actionable advice, often highlighting common mistakes and overlooked risks in real-world environments.

With a strong emphasis on community contribution and knowledge sharing, Mirko is actively building a platform that connects experts, shares experiences, and helps organizations get the most out of their Microsoft 365 investments.