Microsoft Purview Data Quality with Snowflake – Internal Error During DQScane & Profiling and Token Expired Issue

For the described issues, the documented guidance focuses on generic Data Quality internal errors and connectivity problems, plus Snowflake prerequisites.

Issue 1 – Internal service error (DataQualityInternalError)

1. Verify Snowflake prerequisites
   • Ensure Snowflake is configured exactly as per prerequisites:
     • A dedicated role (for example, purview_reader) with read-only access.
     • A dedicated user (for example, purview) using that role as default.
     • Appropriate warehouse, database, schema, and object permissions granted to that role.
   • The documented pattern is:
     • Create role and assign to a parent role:

              USE ROLE ACCOUNTADMIN;
              
              CREATE OR REPLACE ROLE purview_reader;
              GRANT ROLE purview_reader TO ROLE sysadmin;
       

     • Create user and assign role:

              CREATE OR REPLACE USER purview 
                  PASSWORD = '<password>';
              
              ALTER USER purview SET DEFAULT_ROLE = purview_reader;
              GRANT ROLE purview_reader TO USER purview;
       

     • Grant reader rights to the database objects (USAGE on warehouse/database/schema and SELECT on tables/views) as already done.
2. Treat the “Internal service error” as a platform-side failure
   • The documented guidance for similar “Internal system error” / “Internal service error” messages in Purview is that they typically indicate connectivity or configuration issues that require deeper investigation.
   • For Data Quality specifically, the troubleshooting guidance states that generic internal errors can have multiple causes (authorization, connectivity, managed identity access, or internal service problems) and explicitly calls out contacting Microsoft support when these occur.
   • Given that:
     • The connection test succeeds.
     • Schema import succeeds.
     • Snowflake permissions and data types are already validated.
     • Snowflake reports no warehouse activity during DQ runs.
   • This aligns with the class of issues where the Data Quality service fails internally rather than at the Snowflake or permission layer. The recommended next step is to open a support case with Microsoft, providing the correlationId and JobId so the backend logs can be analyzed.

Issue 2 – Special characters in schema names and token expired

1. Special characters in schema names
   • The Data Quality troubleshooting guidance notes that certain schema-related limitations can cause failures (for example, unsupported data types, undefined datatypes, or schema import issues). While it does not explicitly list Snowflake schema-name character restrictions, the behavior described (failure with special characters, success after removing them) is consistent with known schema/metadata limitations.
   • The recommended pattern is to:
     • Use schemas and objects with supported/standard naming (no special characters) when configuring Data Quality.
     • If schema issues appear (blank schema, missing columns, or failures), import the schema again from the Data Quality page and refresh so that Data Quality has a clean, consistent schema.
2. Token expired despite long validity
   • The Data Quality troubleshooting guidance for “Internal service error” and related failures highlights that authentication and authorization problems (for example, expired or invalid credentials, or managed identity access issues) can manifest as generic internal errors.
   • In this case, the “token expired” message, even when the underlying secret or credential appears valid for a year, indicates that the runtime token used by Purview to access Snowflake is no longer valid at execution time.
   • Because token issuance and refresh are handled by the Purview service and its integration with Key Vault and the Snowflake connection, this class of issue falls into the category where the official guidance is to:
     • Revalidate the connection configuration (which has already been done), and
     • Escalate to Microsoft support with correlationId and JobId for backend investigation.

Additional checks and next steps

Within the documented guidance, the additional checks and actions that apply are:

1. Confirm that the Data Quality job is not failing due to unsupported schema or datatypes
   • Ensure that the schema imported into Data Quality has all columns with recognized datatypes and no undefined types.
   • If any columns show as Undefined or the schema appears inconsistent, import the schema again from the Data Quality page and save it.
2. Treat persistent “Internal service error” and token issues as support cases
   • The troubleshooting guidance for both Data Quality and private-link/scan scenarios explicitly states that persistent internal errors, especially when correlationIds are provided and basic configuration is correct, should be escalated to Microsoft support.
   • Provide:
     • CorrelationId and JobId from failing runs.
     • Confirmation that Snowflake prerequisites and permissions are configured as per the documented pattern.
     • Confirmation that connection tests and schema imports succeed.

Given the current documentation, the combination of:

• Successful connection tests and schema import,
• No warehouse activity observed,
• Internal service error and token expired messages,

matches scenarios where backend investigation by Microsoft support is required rather than additional customer-side configuration changes.

References:

• Data quality troubleshooting
• Data governance known issues
• Connect to and manage Snowflake in Microsoft Purview
• Troubleshooting private endpoint configuration for Microsoft Purview accounts
• Data quality error records