Clarification on Purview Data Map Access and Required Roles

Hi Rachel,

1. Microsoft describes Data Map and Unified Catalog as separate governance solutions, with Data Map having its own permission layer.

There are 3 tenant-level role groups that provide broad access to the governance platform - Purview administrator, data source administrator or data governance. Microsoft describes Purview Administrators as managing domains and role assignments, Data Source Administrators as managing sources and scans, and Data Governance as providing access to data governance roles.

However, access to Data Map objects is separately controlled through Data Map permissions. One of the predefined roles is Data Map Reader, which provides read access to Data Map objects.

Microsoft lists it as a Purview role, and it is included in a number of existing role groups such as Compliance Administrator, Data Governance, Data Catalog Curators, Information Protection, etc.

2. Microsoft currently assigns Data Map Writer by default to the Data Catalog Curators role group. This role provides: Create, read, modify and delete actions on Data Map objects and establish relationships between objects.

So for general Data Map object administration/curation:

Data Map Reader = Read

Data Map Writer = Create/read/modify/delete

Data Map Writer does not mean that a user can administer everything involved in scanning. Microsoft has separate roles.

The Data Source Administrators role group manages:

Data sources

Data scans

It contains roles including:

Source Reader

Source Writer

Scan Reader

Scan Writer

Credential Reader

Credential Writer

Microsoft explicitly describes the role group as “Manage data sources and data scans.” So with that in mind, it doesn't mean that you can give somebody the Data Map Writer role and assume they can operate the scanning infrastructure.

3. Not completely - Data Map is still explicitly a Microsoft Purview solution.

Microsoft's current documentation says that Microsoft Purview data governance has two solutions: Data Map and Unified Catalog. Microsoft also then describes Data Map domain and collection permissions separately from Unified Catalog permissions.

4. Sometimes, however this is where Data Map administration and access to the underlying Azure resources need to be separated.

The important difference is Purview permissions control what you can do inside Data Map. Azure RBAC can control whether you can actually access or register the underlying Azure resources.

Microsoft's troubleshooting guidance tells administrators to check Azure IAM and verify that the relevant user has appropriate permissions such as Reader on the Azure resource when registering sources. Microsoft also states that Data Map/Unified Catalog permissions do not grant access to the underlying data itself.

I try to think of it as Purview Data Map permissions govern access to metadata and Data Map objects, while permissions on the underlying Azure or Fabric resources can also determine which assets a user can discover or access. The exact Azure RBAC requirement depends on the source and operation being performed.

One piece of advice I'd give is that you shouldn't give somebody Contributor/Owner at subscription level just because they're administering Purview.

5. For the scenario you've described, I'd be inclined to go with something similar to the below:

A. Data governance viewer - Someone who needs to see assets and lineage, but shouldn't change anything:

Purview: Data Map Reader where required, together with the appropriate domain/collection permissions and any necessary read permissions on the underlying Azure or Fabric resources. This provides read access to relevant Purview metadata without granting unnecessary administrative permissions.

B. Data Map operator

Someone who needs to manage sources and scans.

Purview: Data Source Administrator plus the required Data Map/domain/collection permissions.

This is the person/team responsible for:

Register and manage data sources.

Configure scans and manage scan execution.

Maintain source and scan configuration, subject to the specific Source and Scan permissions assigned.

C. Data curator

Someone responsible for managing Data Map metadata/assets:

Purview: Data Map Writer, typically provided through the Data Catalog Curators role group, plus the appropriate domain/collection permissions.

This is the role I'd associate with:

Curating assets

Modifying metadata

Curating Data Map objects and establishing relationships between objects

Maintaining the catalogue representation

Microsoft's current role definition for Data Map Writer is create/read/modify/delete on Data Map objects.

D. Data Map administrator

For someone responsible for administering the Purview governance structure and Data Map configuration, I'd suggest a combination of:

Purview Administrators for the relevant tenant-level administration and role assignments, Purview Administrators for the relevant tenant-level administration and role assignments, together with the appropriate domain and collection permissions needed to manage the relevant Data Map scope. Add Data Source Administrator permissions if the person also manages sources and scans.

There isn't a single role that should automatically be treated as "Data Map Administrator". For someone responsible for administering the Purview governance structure and Data Map configuration, I'd use the combination of permissions appropriate to those responsibilities. The precise combination should reflect the administrator's responsibilities rather than granting every permission by default.

Regarding not being able to see Data Map as expected, I did a bit of research on this and have the following steps to suggest:

Check whether the account type supports the required Data Map capabilities.

Confirm you're using the new Microsoft Purview portal experience.

Check tenant-level role membership - Purview Administrators/Data Source Administrators/Data Governance as appropriate.

Check Data Map permissions - Data Map Reader/Writer and domain/collection scope.

Check underlying Azure/Fabric Read permissions where applicable.

Allow for RBAC/Entra permission propagation.

It appears that the current Microsoft Purview experience uses a more layered permission model than the traditional "Purview Administrator = access to everything" model.

Microsoft now describes Data Map and Unified Catalog as two separate governance solutions, with Data Map using its own predefined roles together with domain and collection permissions. Tenant-level role groups such as Purview Administrators, Data Source Administrators and Data Governance provide broader administrative capabilities, while roles such as Data Map Reader and Data Map Writer control specific Data Map operations.

Therefore, having the Purview Administrators role does not necessarily mean that a user has every permission required to perform all Data Map, source and scan operations.

For your specific issue, I would first check the Purview account type (Free or Enterprise), then confirm the tenant-level role assignment, followed by Data Map Reader/Writer and domain/collection permissions, and finally any required permissions on the underlying Azure or Fabric resources. Microsoft also notes that newly assigned Entra permissions can take some time to propagate.

From a least-privilege perspective, I would avoid assigning subscription-level Owner or Contributor simply because someone administers Purview. Instead, separate Purview administration, Data Map administration, source/scan administration and underlying Azure resource access wherever practical.

Sorry for the long-winded answer, but I have tried to be thorough - please drop me a reply if you need me to go into anything in more detail!

I will try these out and see what happens. Thank you for taking the time answer this question.