Skip to content
Roesli.
Go back
microsoft-purview

Browse Microsoft Purview permissions as a tree

A tested PowerShell exporter that turns Microsoft Purview Unified Catalog and Data Map permissions into a browsable HTML tree, Markdown, and JSON.

Purview permissions are spread across more than one place. Unified Catalog has catalog and governance-domain roles. Data Map has collection roles. Groups add another layer because the role assignment tells you the group, not necessarily the people behind it.

The practical question is simple:

Who has which role, at which level, and what does that mean in the hierarchy?

I wrote a read-only PowerShell exporter that answers that question with a tree. It keeps governance domains, subdomains, data products, Data Map collections, roles, users, groups, and optional group membership together instead of scattering them across portal screens and spreadsheets.

Download the script

Download Export-PurviewPermissions.ps1

The script uses your existing Azure CLI login. It calls the Purview APIs and Microsoft Graph, then writes three files:

  • Purview-Permissions.html, an interactive tree with filtering and expand/collapse;
  • Purview-Permissions.md, a portable Markdown version; and
  • Purview-Permissions.json, the normalized report data.

What the tree contains

The Unified Catalog side has:

  • catalog-level roles;
  • governance domains and nested subdomains;
  • data products below their domain; and
  • the users and groups assigned to each role.

The Data Map side has the collection hierarchy and collection roles. That distinction matters. A Data Product Owner role in Unified Catalog and a Data Curator role in Data Map are not interchangeable permissions.

Prerequisites

You need:

  1. PowerShell 7;
  2. Azure CLI;
  3. an authenticated Azure CLI session;
  4. permission to read the Purview Unified Catalog and Data Map policy APIs; and
  5. Microsoft Graph permission to resolve directory object names.

Sign in and run:

az login
pwsh .\Export-PurviewPermissions.ps1

By default, group membership is not expanded:

pwsh .\Export-PurviewPermissions.ps1

If you also want the transitive users behind assigned groups:

pwsh .\Export-PurviewPermissions.ps1 -ExpandGroups

The expanded mode needs Microsoft Graph group-membership permission. Microsoft documents GroupMember.ReadBasic.All as the least-privileged permission for reading transitive group members. Hidden-membership groups need the additional hidden-membership permission.

Why the optional switch matters

Resolving a group name is useful. Expanding every group into users is more sensitive and can require more directory privileges. That is why the default report stops at the group. Use -ExpandGroups only when the access review requires it and your Graph consent allows it.

What this does not prove

This is an inventory of Purview governance assignments. It does not calculate effective access to every table, file, Power BI semantic model, or Fabric item. Unified Catalog discovery is also influenced by Data Map permissions and permissions on the underlying resource.

In practice, use this report as the starting point for an access review. Then validate the source-resource permissions for the assets that matter.

Validation

I tested the exporter against a Purview tenant with:

  • 3 governance domains;
  • 4 data products;
  • 6 Data Map collections;
  • 59 role assignments;
  • a standard report with no Graph warnings; and
  • an expanded report that resolved one assigned group to two transitive users.

The script is read-only. It does not change Purview roles, collections, domains, data products, or group membership.

Handle the output carefully

The report can contain names, email-style user principal names, object IDs, governance structure, and role assignments. That is useful audit data and potentially sensitive organizational information.

Do not publish the generated HTML, Markdown, or JSON report. Store it in an appropriately protected location and delete temporary copies when the review is complete.

My take

The interesting part is not that Purview has many roles. It is that permissions exist at different layers, while the portal makes you inspect those layers one object at a time.

A repeatable tree turns that into something you can compare, review, and discuss with domain owners. It does not replace an access review, but it gives the review a proper starting point.

Sources


Share this post:

Continue exploring

Previous Post
Fabric Monitor hub: one place to see what failed
Next Post
Run Unity Catalog managed tables on OneLake
Community

Join the conversation

Sign in with GitHub to leave a comment.

GitHub

Loading comments…

Sign in with GitHub to comment