Forum Discussion

JohnYang's avatar
JohnYang
Copper Contributor
Mar 14, 2026
Solved

Integrate MS Purview with ServiceNow for Data Governance

Hi team,

We are planning to leverage Microsoft Purview for core Data Governance (DG) capabilities and build the remaining DG functions on ServiceNow. We have two key questions as we design the target‑state architecture:

1. What is the recommended split of DG capabilities between Microsoft Purview and ServiceNow?

2. How should data be shared and synchronized between Purview and ServiceNow to keep governance processes aligned and up to date?

Thanks!

  • Howdy JohnYang​ 

    Good question. Worth separating what Microsoft built versus what you'll need to design yourself.

    What Purview owns

    Keep these in Purview. ServiceNow doesn't come close:

    • Data discovery, classification, and sensitivity labeling across Azure and M365
    • Data lineage across pipelines and assets
    • Business glossary and Unified Catalog (GA'd late 2025)
    • Data quality scanning and rule execution
    • Access policy management at the data layer

    Don't try to replicate any of these in ServiceNow.

    What ServiceNow owns

    Keep these in ServiceNow. It's where your ITSM process muscle lives:

    • Data governance issue tracking and remediation workflows
    • Access requests requiring human approval and fulfillment steps
    • Policy exception management and stewardship task assignment
    • Cross-team escalation for data quality failures

    The integration layer

    Two documented paths, and you'll likely use both.

    Purview-initiated, ServiceNow-triggered. Purview supports native ServiceNow actions inside its workflow engine. You can add a ServiceNow action to any Purview workflow using a basic auth credential stored in Azure Key Vault. Data quality failure fires, Purview creates the ServiceNow ticket. No middleware required.

    ServiceNow calling Purview. Purview exposes a full REST API covering data map queries, classification results, and glossary management. ServiceNow calls these endpoints to pull asset metadata, check classification status, or trigger scans on demand. For anything the native connector doesn't cover, Purview workflows also support an HTTP connector using REST, with basic auth and service principal credentials.

    Honest gaps to plan around

    The native ServiceNow workflow integration is still marked preview in the classic governance portal. Verify availability in your tenant's Unified Catalog experience before building against it.

    There's no out-of-the-box bidirectional sync. Keeping ServiceNow records and Purview assets aligned over time requires a pipeline you build and maintain. Logic Apps or Azure Functions are the practical middle tier for scheduled sync.

    Sensitivity labels and classification results don't push to ServiceNow automatically. If ServiceNow workflows need classification context, you pull it via the Purview REST API or build an event-driven sync on classification changes.

    Start with Purview-to-ServiceNow first. Get a working workflow that fires a ServiceNow incident on a data quality failure. That validates the auth configuration before you tackle bidirectional flows.

    Please mark as solution if you find this helpful. It helps others in the community find the solution quickly. 🖖

3 Replies

  • Howdy JohnYang​ 

    Good question. Worth separating what Microsoft built versus what you'll need to design yourself.

    What Purview owns

    Keep these in Purview. ServiceNow doesn't come close:

    • Data discovery, classification, and sensitivity labeling across Azure and M365
    • Data lineage across pipelines and assets
    • Business glossary and Unified Catalog (GA'd late 2025)
    • Data quality scanning and rule execution
    • Access policy management at the data layer

    Don't try to replicate any of these in ServiceNow.

    What ServiceNow owns

    Keep these in ServiceNow. It's where your ITSM process muscle lives:

    • Data governance issue tracking and remediation workflows
    • Access requests requiring human approval and fulfillment steps
    • Policy exception management and stewardship task assignment
    • Cross-team escalation for data quality failures

    The integration layer

    Two documented paths, and you'll likely use both.

    Purview-initiated, ServiceNow-triggered. Purview supports native ServiceNow actions inside its workflow engine. You can add a ServiceNow action to any Purview workflow using a basic auth credential stored in Azure Key Vault. Data quality failure fires, Purview creates the ServiceNow ticket. No middleware required.

    ServiceNow calling Purview. Purview exposes a full REST API covering data map queries, classification results, and glossary management. ServiceNow calls these endpoints to pull asset metadata, check classification status, or trigger scans on demand. For anything the native connector doesn't cover, Purview workflows also support an HTTP connector using REST, with basic auth and service principal credentials.

    Honest gaps to plan around

    The native ServiceNow workflow integration is still marked preview in the classic governance portal. Verify availability in your tenant's Unified Catalog experience before building against it.

    There's no out-of-the-box bidirectional sync. Keeping ServiceNow records and Purview assets aligned over time requires a pipeline you build and maintain. Logic Apps or Azure Functions are the practical middle tier for scheduled sync.

    Sensitivity labels and classification results don't push to ServiceNow automatically. If ServiceNow workflows need classification context, you pull it via the Purview REST API or build an event-driven sync on classification changes.

    Start with Purview-to-ServiceNow first. Get a working workflow that fires a ServiceNow incident on a data quality failure. That validates the auth configuration before you tackle bidirectional flows.

    Please mark as solution if you find this helpful. It helps others in the community find the solution quickly. 🖖

    • JohnYang's avatar
      JohnYang
      Copper Contributor

      Love your response!

      To take this further — what would a practical phased approach look like for ramping up Data Governance across both Microsoft Purview and ServiceNow?

      I’m particularly interested in how others structure the rollout from foundational setup through metadata onboarding, workflow integration, and into quality/risk/compliance operations.

      Any recommended stages, sequencing, or best‑practice roadmaps would be greatly appreciated!

  • Hello JohnYang,

    1. What is the recommended split of DG capabilities between Microsoft Purview and ServiceNow?In brief, Purview is capable of scanning your data assets across the org and gather the metadata using datamap and build governance domains and curate data products using Unified Catalog. 
      Using ServiceNow integration with Purview, you can manage governance events in Purview to automatically create or update Service Now records. 
      For Purview capabilities and overall workflow, refer to: Learn about data governance with Microsoft Purview | Microsoft Learn
    2. How should data be shared and synchronized between Purview and ServiceNow to keep governance processes aligned and up to date?
      Refer to: Connect to ServiceNow in workflows | Microsoft Learn

    Hope this helps!

    Please mark as solution, if you find the answer helpful. This will assist others in the community who encounter a similar issue, enabling them to quickly find the solution and benefit from the guidance provided.