Purview Custom SQL query

Hi @Anuj Pratap Solanki
To confirm clearly - full SQL-based rules are not supported today in Purview Health Management. The rule engine is intentionally limited to expression-based logic (column-level conditions), and there isn’t a way to plug in arbitrary SQL for validation.

That said, for SQL-driven scenarios, the expectation is to handle those checks outside Purview and use Purview mainly for visibility and governance, not execution of complex query logic.

What typically works in practice:

Pre-validation using SQL (ADF / Synapse / Databricks)

Run your SQL-based checks as part of your pipeline and:

• Store results (pass/fail, metrics)
• Optionally surface them back via metadata or reporting

Use views to encapsulate logic

If your validation can be expressed as a dataset/view:

• Create a SQL view with your logic
• Then apply Purview rules on top of that derived dataset

Hybrid approach (most common)

• SQL → does heavy validation
• Purview → tracks data quality status, ownership, and governance

Purview Data Quality rules are designed to be:

• Source-agnostic
• Lightweight and standardized

Allowing full SQL would make rule execution dependent on specific engines and break that abstraction.

There’s no public confirmation yet for native SQL rule support. If this is critical for your scenario, it’s worth raising via feedback channels so the product team can track demand.

Hope this helps.

Hi Anuj Pratap Solanki,
You’re on the right track exploring the Data Quality Rules experience in Purview. At the moment, full SQL-based validations aren’t supported in Health Management. The custom rule framework is limited to the built-in expression logic (column + operator/function + condition), and there isn’t an option to plug in a standalone SQL query for rule evaluation.

For scenarios where SQL logic is required, a common approach is to handle those validations outside Purview. For example, you can run your SQL checks as part of an ETL or data validation pipeline using services like Azure Data Factory or Azure Synapse Analytics, and then capture or surface the results back in Purview (for example via metadata enrichment or lineage context).

Another practical workaround is to encapsulate your SQL logic into views or derived columns at the source, and then apply Purview’s expression-based rules on top of those. This keeps your rule definitions within Purview while still leveraging SQL where needed.

As of now, there’s no publicly available roadmap confirming support for SQL-based rules in this area. If this capability is important for your use case, I’d recommend sharing it through the feedback channel so the product team can track demand: https://aka.ms/purviewideas

You can also refer to the current documentation for supported rule capabilities here: https://dori-uw-1.kuma-moon.com/en-us/purview/data-quality-rules

Hope this helps! Let me know if you’d like to walk through your specific SQL logic , happy to suggest how it can be adapted.