Request for Required Roles and Permissions for Microsoft Purview Governance Implementation

Hi SudhakarReddy Marepalli,
Thankyou for reaching Microsoft Q&A!

Based on the activities you’re enabling in Microsoft Purview, you can proceed with the following role assignments to unblock implementation.

For working with data products, including creating and managing custom attributes and defining business concept attributes, you’ll need Data Curator access on the target collection. This role provides the required permissions to manage metadata, glossary terms, and custom attributes in the Unified Catalog. If delegation or access control needs to be handled within the collection, Collection Administrator can be assigned in addition.

For data observability scenarios such as profiling, data quality checks, and anomaly detection, ensure that a Data Source Administrator is assigned to register sources and run scans, as scans are what enable profiling and data extraction. Alongside this, Data Curator access is required to configure rules, enrich metadata, and work with the results. Access to view data health and insights is covered through standard read permissions on the catalog.

For sensitivity labels, these are created and managed through Microsoft Purview Information Protection. To create and publish labels, assign either Information Protection Administrator or Compliance Administrator in Microsoft 365. Once labels are configured and scans are in place, they will be visible in Purview, and users with catalog access (such as Data Curator or Data Reader) will be able to view them on assets.

For workflow automation, including approval and stewardship workflows, assign the Workflow Administrator role to users who will design and manage workflows. They should also have at least read access to the catalog to associate workflows with the relevant assets.

assigning Data Curator (for governance and metadata), Data Source Administrator (for scanning and observability enablement), Workflow Administrator (for workflows), and the appropriate Microsoft 365 roles for sensitivity labeling will cover the scenarios you outlined. Additionally, please ensure that Data Quality/Data Health and workflow features are enabled in your Purview account, and that the required licensing for sensitivity labeling is in place.

For reference:

https://dotnet.territoriali.olinfo.it/purview/data-governance-roles-permissions https://dotnet.territoriali.olinfo.it/azure/purview/catalog-permissions

https://dotnet.territoriali.olinfo.it/purview/purview-information-protection-overview

Please let me know if you’d like help validating role assignments for a specific collection or scenario.

Below is a mapping of the governance capabilities to the roles and permission layers that are documented for Microsoft Purview Data Governance (Unified Catalog + Data Map). Only capabilities explicitly covered in the context are listed.

1. Role model overview (what layers matter)

From the documentation, permissions relevant to Purview Data Governance are split into:

1. Tenant/organization role groups (Purview portal level)
   • Purview Administrators
   • Data Source Administrators
   • Data Governance
2. Unified Catalog roles (catalog + governance domain level)
   • Catalog level: Data Governance Administrator, Data Health Owner, Data Health Reader, Global Catalog Reader
   • Governance domain level: Governance Domain Owner, Governance Domain Creator, Data Steward, Data Product Owner, Governance Domain Reader, Local Catalog Reader, plus data quality / profiling sub‑roles
3. Data Map permissions (collections/domains in Data Map)
   • Separate Data Map roles are required to browse and attach assets to data products.

The documentation also notes that governance roles and role groups “cover only broad access” and that solution‑specific permissions (for example, Information Protection / sensitivity labels) are separate.

2. Data Observability (data quality monitoring, profiling, anomaly detection)

Data observability in Unified Catalog uses the same roles as the rest of the Unified Catalog:

• To access observability views and data estate health
  • One of the following catalog / domain roles is required:
    • Data Steward
    • Data Product Owner
    • Governance Domain Owner
    • Governance Domain Creator
  • Catalog readers (Global Catalog Reader / Local Catalog Reader) cannot access the broader Data Observability explorer view; they can only view published concepts.
• To work with data quality and profiling within a governance domain (sub‑roles):
  • Data Profile Steward
    • Can run data profiling jobs and access profiling insight details.
    • Can browse all data quality insights and monitor profiling jobs.
    • Requires: Governance Domain Reader + Data Product Owner.
  • Data Quality Steward
    • Can manage data quality rules, run data quality scanning, browse insights, configure schedules, thresholds, and alerts.
    • Requires: Governance Domain Reader + Data Product Owner.
  • Data Quality Reader / Data Quality Metadata Reader / Data Profile Reader
    • Read‑only or limited insight roles.
    • Each requires: Governance Domain Reader and either Global Catalog Reader or Local Catalog Reader.
• Additional requirement for working with data products
  • For Data Product Owners and Data Stewards to add data assets to data products, they must also have Data Map permissions to read those assets in Data Map.

Minimum roles for data observability work in a domain

• Operational ownership (configure rules, run scans, monitor):
  • Data Product Owner + Governance Domain Reader + Data Quality Steward (and optionally Data Profile Steward).
• Read/analysis only:
  • Governance Domain Reader + (Global Catalog Reader or Local Catalog Reader) + Data Quality Reader or Data Quality Metadata Reader or Data Profile Reader.

3. Custom attributes in Data Products and Business Concept Attributes

The context describes:

• Custom attributes for business concepts and domains are visible in the Details → Custom attributes area of a governance domain.
• Governance domain roles:
  • Data Product Owner*: Can create, update, and read data products within their governance domain; can read and build relationships with concepts.
  • Data Steward*: Can create, update, and read artifacts and policies within their governance domain; can also read artifacts from other domains.
  • Governance Domain Owner: Can delegate all other governance domain permissions and configure domain‑level policies and alerts.
  • Governance Domain Creator: Can create domains and delegate Governance Domain Owner.

*Both Data Product Owners and Data Stewards need Data Map permissions to read assets they want to attach to data products.

The documentation does not spell out “custom attributes in data products” as a separate permission, but it explicitly states that Data Stewards and Data Product Owners can create and update artifacts within their governance domain.

Minimum roles for working with attributes in governance domains

1. Create and manage custom attributes within Data Products
   • Governance domain level:
     • Data Product Owner or Data Steward in the relevant governance domain.
   • Plus Data Map:
     • Sufficient Data Map permissions on the mapped collection to read and attach assets.
2. Define and edit business concept attributes
   • Governance domain level:
     • Data Steward or Governance Domain Owner (for broad configuration and policy control in the domain).
   • Catalog visibility:
     • Global Catalog Reader or Local Catalog Reader as needed to see published concepts.

4. Workflow automation (approval / stewardship / lifecycle)

The provided context does not describe workflow automation or its specific roles. No additional roles beyond the standard governance domain and catalog roles can be stated from this content.

5. Sensitivity Labels (MIP) – creation, publishing, and column‑level application

The context provided does not cover Microsoft Information Protection sensitivity labels, their creation, publishing, or how they are applied at column level in Purview. It also does not list the roles required for label management or label visibility in Data Map / Unified Catalog.

6. Data Map permissions and tenant role groups

For all of the above governance activities to work end‑to‑end, the following layers are relevant:

• Tenant level role groups (Purview portal):
  • Purview Administrators role group
    • Can create, edit, and delete domains and perform role assignments.
  • Data Governance role group
    • Grants access to data governance roles within Microsoft Purview.
  • Data Source Administrators role group
    • Manage data sources and data scans in the Data Map.
• Data Map permissions
  • Required so users can browse and attach assets to data products and see assets in searches.
  • Domains and collections are used to group assets and manage access control.
• Role management prerequisite
  • To add users or groups to a Purview role group, a user must hold the Role management role in the Purview portal.

Minimum combined setup for a typical governance practitioner

For a user who needs to:

• Own data products and configure data quality/observability in a domain
• Work with attributes and policies in that domain

Assign:

1. Tenant / portal level:
   • Member of Data Governance role group (to access data governance roles), and role assignments performed by someone in Purview Administrators or with Role management.
2. Unified Catalog:
   • Governance Domain Reader for the domain.
   • Data Product Owner and/or Data Steward for that domain.
   • For observability and data quality operations: Data Quality Steward and/or Data Profile Steward.
3. Catalog visibility:
   • Global Catalog Reader (or Local Catalog Reader if access must be restricted to specific domains).
4. Data Map:
   • Appropriate Data Map collection roles on the mapped collection so they can read and attach assets.

7. Additional enablement, licensing, or permissions

From the context:

• Governance roles and role groups “cover only broad access to the Microsoft Purview Data Map and Unified Catalog. For more access, Microsoft Purview governance uses a combination of role groups, data access, and solution‑specific permissions.”
• For features outside the Purview portal (for example, Exchange mail flow rules), separate admin centers and permissions are required.

The context does not provide specific licensing requirements or additional feature enablement steps for:

• Data observability
• Sensitivity labels
• Workflow automation

Only that observability requires a brief setup process and uses the same roles as Unified Catalog.

8. Direct answers to the specific clarification questions

1. Minimum roles required to:
   • Create and manage custom attributes within Data Products
     • Governance domain: Data Product Owner or Data Steward in that domain.
     • Plus Data Map permissions on the mapped collection to work with underlying assets.
   • Define and edit business concept attributes
     • Governance domain: Data Steward or Governance Domain Owner.
     • Catalog visibility: Global Catalog Reader or Local Catalog Reader as needed.
   • Configure workflow automation within Purview
     • Not covered in the provided documentation; no specific roles can be stated from this context.
2. Roles required to:
   • Create, publish, and apply Sensitivity Labels at column level
   • Enable label visibility inside Data Map / Unified Catalog
   These are not described in the provided context; no role mapping can be given from this content.
3. For data observability capabilities:
   • Roles needed to work on data observability under Health management and use it in data products
     • Catalog / domain roles with observability access:
       • Data Steward, Data Product Owner, Governance Domain Owner, or Governance Domain Creator.
     • For active data quality / profiling operations:
       • Governance Domain Reader + Data Product Owner, plus:
         • Data Quality Steward (data quality rules, scans, schedules, alerts), and/or
         • Data Profile Steward (profiling jobs and profiling insights).
     • For read‑only observability:
       • Governance Domain Reader + (Global Catalog Reader or Local Catalog Reader) + Data Quality Reader / Data Quality Metadata Reader / Data Profile Reader.
   • Additional feature enablements, licensing, or permissions
     • The context only states that observability requires a setup process and uses the same roles as Unified Catalog; it does not list licensing or extra permissions.

References:

• Data governance roles and permissions in Microsoft Purview
• Permissions in the Microsoft Purview portal
• Governance roles and permissions for classic Data Catalog in free and enterprise account types
• Create and manage governance domains