microsoft purview
89 TopicsSharing: PDF readers that support Purview labels
As I was researching on Adobe Acrobat reader and Sensitivity labels, I decided to check if the common alternative PDF readers out there are able to support Purview MIP Sensitivity labels. There is already a published documentation on this for SharePoint-Compatible PDF readers that supports Microsoft IRM: https://learn.microsoft.com/en-us/purview/sp-compatible-pdf-readers-for-irm (last updated Nov-2023) but I wanted to see if these same PDF readers supports the ability for end-users to use/ select labels similar to that of Adobe Acrobat As of 11-June-2025; atleast one of them clearly do: Nitro PDF: Yes. Documentation shows that users can see and use the sensitivity labels. PDF -X.change Editor: Yes. Documentation show that users can see and use the sensitivity labels. (check the official website, I can't hyperlink it because the site is blocked. FOX PDF editor: No. Documentation only states RMS and not clear if it show Purview labels. This is for F.O.X.I.T editor (spelled without the ".") but for some reason there is a community ban on that word and it won't allow me to post the full name PDFescape: No. Sumatra PDF: No Okular: No If there are other PDF readers that I've missed, I encourage you list it down in the comment below. Would love to grow this list.895Views4likes3CommentsPurview Data Map scanning Microsoft Fabric and no classifications applied or scan rule sets
Microsoft Purview cannot currently apply built-in or custom classifications (including sensitive information types) to metadata discovered from Microsoft Fabric workspace scans. While Purview can register Fabric workspaces and extract structural metadata (workspaces, Lakehouses, Warehouses, tables, columns, and limited lineage), classification rules are not executed against Fabric assets in the same way they are for supported sources such as Azure SQL, ADLS Gen2, or on-prem databases. This results in classification gaps across a core enterprise analytics platform. Why This Is a Significant Service Omission 1. Breaks the Core Value Proposition of Purview 2. Undermines Regulatory and Risk Management Controls 3. Creates an Inconsistent Governance Experience 4. Blocks Downstream Purview Capabilities 5. Forces Anti-Patterns and Workarounds The lack of automated classification support for Microsoft Fabric workspace data represents a material service omission in Microsoft Purview, significantly limiting its effectiveness as a unified data governance platform and introducing avoidable compliance, operational, and assurance risks—particularly in regulated environments. Are there plans to improve this and if so what are the timescales?234Views3likes1CommentCan´t Sign confidential documents
Hello, I have a problem. I want to send confidential contracts to customers for signing with Adobe DocuSign. This contracts have a label "confidential" from purview and are encrypted. But now the customer cant sign the contract with DocuSign because of the encryption. Is there a way that they can sign the document? We must encrypt the documents because compliance reasons and ISMS. Thank you.142Views2likes5CommentsWorkaround Enabling Purview Data Quality & Profiling for Cross-Tenant Microsoft Fabric Assets
The Challenge: Cross-Tenant Data Quality Blockers Like many of you, I have been managing a complex architecture where Microsoft Purview sits in Tenant A and Microsoft Fabric resides in Tenant B. While we can achieve basic metadata scanning (with some configuration), I hit a hard wall when trying to enable Data Quality (DQ) scanning. Purview's native Data Quality scan for Fabric currently faces limitations in cross-tenant scenarios, preventing us from running Profiling or applying DQ Rules directly on the remote Delta tables. The Experiment: "Governance Staging" Architecture rather than waiting for a native API fix, I conducted an experiment to bridge this gap using a "Data Staging" approach. The goal was to bring the data's "physicality" into the same tenant as Purview to unlock the full DQ engine. The Solution Steps: Data Movement (Tenant B to Tenant A): Inside the Fabric Workspace (Tenant B), I created a Fabric Data Pipeline. I used this to export the critical Delta Tables as Parquet files to an ADLS Gen2 account located in Tenant A (the same tenant as Purview). Note: You can schedule this to run daily to keep the "Governance Copy" fresh. Native Scanning (Tenant A): I registered this ADLS Gen2 account as a source in Purview. Because both Purview and the ADLS account are in the same tenant, the scan was seamless, instantaneous, and required no complex authentication hurdles. Activating Data Quality: Once the Parquet files were scanned, I attached these assets to a Data Product in the Purview Data Governance portal. The Results: The results were immediate and successful. Because the data now resides on a fully supported, same-tenant ADLS Gen2 surface: ✅ Data Profiling: I could instantly see column statistics, null distributions, and value patterns. ✅ DQ Rules: I was able to apply custom logic and business rules to the data. ✅ Scans: The DQ scan ran successfully, generating a Data Quality Score for our Fabric data. Conclusion: While we await native cross-tenant "Live View" support for DQ in Fabric, this workaround works today. It allows you to leverage the full power of Microsoft Purview's Data Quality engine immediately. If you are blocked by tenant boundaries, I highly recommend setting up a lightweight "Governance Staging" container in your primary tenant. Has anyone else experimented with similar staging patterns for Governance? Let's discuss below.Solved227Views2likes3CommentsManaging Multi-Tenant Azure/365: Workarounds for Cross-Tenant Limitations in Purview and Fabric
I am working in a Microsoft Azure/365 multi-tenant setting due to some constraints. I am using Purview (Tenant1) and Fabric (Tenant2), M365 in (Tenant 2). I'm facing issues with various solutions due to cross tenant limitation for eg: Data Quality Connection, Metadata ingestion, lineage, etc. To overcome this I am exploring various workarounds. Key Question: 1. Are there proven workarounds or solutions to manage data estate in this scenario? (Can't merge /migrate tenants)239Views2likes1CommentMicrosoft Purview - Structured Database Management, Governance, Security and Protection
Since Microsoft Purview is a Data Governance and Data Security platform, I need to integrate Microsoft Purview with both structured and non-structured databases hosted in the public cloud and on-premises. The goal is to leverage Microsoft Purview to manage user roles and permissions, enforce data loss prevention policies and rules (e.g., statement-based rules), mask specific columns to restrict certain users from viewing actual data, implement field-level encryption for database fields, and, most importantly, ensure data quality and integrity by preventing unauthorized direct modifications. I am uncertain about the current capabilities of Microsoft Purview to meet the mentioned requirements. I believe that some features may already be available, while others might not be supported yet.226Views2likes4CommentsAuto-labelling does not support content marking
We’ve hit a limitation with service-side auto-labeling in Purview: when a sensitivity label is applied by an auto-labeling policy, any configured visual markings (headers, footers, watermarks) are not written into the document. A further complication is that there is a requirement which includes a custom script that applies sensitivity labels at the folder level and relies on the service-side engine to cascade those labels down to the folder's contents. This means automation isn't just a 'nice to have' for scale — it is a core dependency of our labeling architecture. The inability to also apply visual markings through this same automated path creates a direct gap in our compliance posture and the MS solution. For environments where visible classification is mandated by regulation, this effectively means we can’t rely on service-side auto-labeling alone, which is a big constraint. I’d really appreciate: Any confirmed best practices/workarounds others are using, and Input from the product team on whether server-side visual markings tied to auto-labeling are being considered / and what to consider meeting this requirement as an alternativeSolved75Views1like1CommentTest DLP Policy: On-Prem
We have DLP policies based on SIT and it is working well for various locations such as Sharepoint, Exchange and Endpoint devices. But the DLP policy for On-Prem Nas shares is not matching when used with Microsoft Information Protection Scanner. DLP Rule: Conditions Content contains any of these sensitive info types: Credit Card Number U.S. Bank Account Number U.S. Driver's License Number U.S. Individual Taxpayer Identification Number (ITIN) U.S. Social Security Number (SSN) The policy is visible to the Scanner and it is being logged as being executed MSIP.Lib MSIP.Scanner (30548) Executing policy: Data Discovery On-Prem, policyId: 85........................ and the MIP reports are listing files with these SITs The results Information Type Name - Credit Card Number U.S. Social Security Number (SSN) U.S. Bank Account Number Action - Classified Dlp Mode -- Test Dlp Status -- Skipped Dlp Comment -- No match There is no other information in logs. Why is the DLP policy not matching and how can I test the policy ? thanks120Views1like2CommentsPurview Unified Catalogue Gov Domains Numeric Prefixing
Has Anyone Tried Numeric Prefixing for Governance Domains in Purview? Context: We introduced a structured numeric prefixing system for governance domains in Microsoft Purview to make hierarchical sorting more intuitive. What we did: Parent domains use a base prefix ending in .00 (e.g., 02.00 Group). Child domains are numbered sequentially (e.g., 02.01 Directorate, 02.01.01 Team). Why: Purview sorts domains alphabetically, which caused child domains (e.g., 02.01) to appear above their parent (02 Group). Adding .00 ensures parents always sort before children, creating a clear hierarchy. How it works: All already have 01.00- Top-level groups: 02.00 Directorates: 02.01, 02.02 Teams/Units: 02.01.01 This approach guarantees correct sorting, clear hierarchy, and scalability for future additions? Question for the community: Has anyone else implemented a similar numeric prefixing approach in Purview? Do you think this is a good idea for maintaining clarity and scalability? Any alternative strategies you’ve found effective?Solved70Views1like1Comment