Forum Discussion
Integrate MS Purview with ServiceNow for Data Governance
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. 🖖
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. 🖖
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!