Pinned Posts
Forum Widgets
Latest Discussions
Microsoft Purview Roles for Data Consumers in a Data Mesh & Data Democratisation Environment
Reformatted Discussion for Community Feedback Recommended Microsoft Purview Roles for Data Consumers in a Data Mesh & Data Democratisation Environment I’m seeking guidance on whether the following set of Microsoft Purview roles is appropriate for typical data consumers within a Data Mesh-aligned organisation. The approach aims to support data democratisation while maintaining least-privilege access. Data consumers (All users) would be placed into a dedicated security group assigned to these roles, ensuring they have the best possible search experience across the Microsoft Purview Unified Catalogue, Data Map, and Data Health features. Unified Catalog Settings Global Catalog Reader Provides read-only visibility of all catalogued assets across the organisation. This role supports governance, compliance, and data discovery without granting modification rights. Using Global Catalog Reader simplifies onboarding and improves usability by giving users a consistent view of published business concepts and data products across all governance domains. Without it, visibility must be managed domain by domain through roles such as Governance Domain Reader or Local Catalog Reader, which increases administrative effort and limits discoverability. Sensitive domains can still apply additional scoped roles where required. Data Health Reader Allows users to view data health metrics such as completeness, freshness, and anomaly indicators. This supports data stewards, quality teams, and analysts in monitoring reliability without the ability to change data or rules. Unified Catalog Governance Domain Roles Data Quality Reader Provides insight into data quality rules and results within a governance domain. Useful for users who need to understand quality issues or compliance status without editing capabilities. Data Profile Reader (Conditional) Enables access to profiling information such as distributions, null counts, and detected patterns. However, profiling data may reveal sensitive information, so this role is best reserved for trusted analysts or stewards rather than being broadly granted to all data consumers. Data Map Role Assignments Data Reader Grants read-only access to metadata and lineage across the data map. This transparency is important for impact assessments, understanding dependencies, and supporting governance processes. Insights Reader Provides access to Purview Insights dashboards, including usage statistics, scanning activity, and classification trends. This role is typically valuable for managers or governance leads monitoring adoption and compliance. Summary Together, these roles aim to give data consumers the access they need for discovery, quality awareness, and understanding lineage; without exposing sensitive data or granting any capability to modify assets. The intention is to follow least-privilege practice while enabling meaningful self-service analytics.Sensitivity Labels and CoPilot - "No AI"
As a Purview Administrator, I recently received a request that might resonate with many of you: add a “No AI” designation to every sublabel we have. Why? Because our contracts and EULAs explicitly state that certain documents must not be used with AI tools. This raises an important question: What’s the best way to implement this without creating unnecessary complexity? The Challenge If we simply append “NoAI” to every existing label and sublabel, we end up duplicating our entire labeling structure. For example, if you follow Microsoft’s guidance on default sensitivity labels and policies, doing this “times two” for every label and sublabel is clearly not scalable. How do you deploy it? Best regards Stephan
DLP Rule for Exchange using ExceptIfRecipientDomainIs not working any more
Hello, we had setup a DLP Rule for Exchange workloads that only allows sending to specific external recipients in a list we provide via populating the ExceptIfRecipientDomainIs attribute. This has been working fine until a few days back, when suddenly the rule was failing to apply on end users (domain is listed in the Rule's ExceptIfRecipientDomainIs) and email gets blocked. I then realized that the attribute is not populated anymore via Powershell and comes back empty! (Get-DlpComplianceRule -Identity "DLPRULE").ExceptIfRecipientDomainIs At the same time, the Rule on the compliance.microsoft.com portal shows up properly with the domains in question. I then noticed that those domains now only appear under the AdvancedRule attribute only. (Get-DlpComplianceRule -Identity "DLPRULE") | select -expand advancedrule So it seems there has been some change in DLP rules by the compliance team at Microsoft?
Issue with the Canadian Drivers License SIT
Did any face an issue with the Canadian Driver's License SIT in the DLP policy? We see a lot of false positives especially around BC province number, NB, PrinceEdward Island and Saskatchewan. These provinces has just digits which can flag any kind of digits. Even if we use some custom RegEx and reduced keyword list, it still flags a lot of false positives. We see this as more and more customers are not happy with it. Has anyone found a breakthrough or best solution for deploying the Canadian Driver's License DLP?Downgrading of encrypted label (User defined permission) in SPO to Desktop app
Hi I have a file stored in SharePoint that was originally labeled Restricted with user-defined encryption. When I open the word file from SharePoint using a desktop Office application and downgrade the label to Internal, the original encryption and permissions are still retained. This issue occurs only when opening the file from SharePoint into the desktop app—the previous protection settings persist even though the sensitivity label correctly updates to Internal. I’ve attached a screenshot for reference. Is there any official Microsoft documentation that explains why this behavior occurs and the underlying reason for it? Additionally, what is the recommended workaround if I want to fully remove user-defined permissions when downgrading the label? I have already tried reapplying the Internal label, but the file remains encrypted with the prior permissions.
Need help with DLP Policy in Purview
One of our requirements is to block Copilot from discovering or querying internal files. Specifically, files labeled Internal or Confidential should not be discoverable or accessible by Copilot. I was able to obtain some step-by-step instructions from Copilot, but the required settings do not appear in our Purview portal, likely due to our E3 licensing. Has anybody created a DLP policy to achieve this or do you have a
MS Purview Data Map - Sensitivity Label - Atlas API
Hi Everyone, Can someone confirm if it’s possible to update the Sensitivity label column in the Microsoft Purview Unified Data Catalog using the Atlas API? Since Microsoft Fabric currently does not support the auto-labeling feature in the Data Map, can we apply sensitivity labels to Fabric assets in the catalog through the Atlas API? Regards, BanuMurali
