Skip to main content

​
Connection & Authentication

How do I connect multiple Snowflake accounts? Create a separate connector for each Snowflake account. Each connector has its own credentials, scope configuration, and job schedules. You can name them to distinguish environments (e.g., snowflake-prod, snowflake-dev). How do I monitor multiple databases within one account? Run the permissions SQL script once per database, replacing <database_name> each time. Prizm automatically includes all databases the role has been granted USAGE on. Alternatively, use the Include pattern * in the asset scope to include all accessible databases. Which authentication methods are supported? Prizm supports Username & Password, Key Pair (RSA), and OAuth 2.0. Key Pair is recommended for production environments — it avoids password rotation disruptions and is compatible with Snowflake IP-allowlist policies. Can I use a pre-existing Snowflake role instead of creating PRIZM_ROLE? Yes. Any role with the required grants will work. The SQL script uses PRIZM_ROLE as the example name — substitute your preferred role name throughout.

​
Permissions

What is IMPORTED PRIVILEGES and why does Prizm need it? IMPORTED PRIVILEGES grants access to the SNOWFLAKE shared database, which contains the ACCOUNT_USAGE schema. Prizm uses this for:
  • Query performance history (QUERY_HISTORY)
  • Warehouse compute metering (WAREHOUSE_METERING_HISTORY)
  • Task run history (TASK_HISTORY)
  • Snowpipe load history (COPY_HISTORY)
  • Enterprise column-level lineage (CORE.GET_LINEAGE)
  • Tag references (TAG_REFERENCES)
Without this grant, tag sync, pipeline observability, performance metrics, and Enterprise lineage will all be unavailable. What is the minimum permission set if I only want catalog discovery? For catalog-only (no observability, quality, lineage, or performance): 
GRANT USAGE ON WAREHOUSE <warehouse_name> TO ROLE PRIZM_ROLE;
GRANT USAGE ON DATABASE <database_name> TO ROLE PRIZM_ROLE;
GRANT USAGE ON ALL SCHEMAS IN DATABASE <database_name> TO ROLE PRIZM_ROLE;
GRANT USAGE ON FUTURE SCHEMAS IN DATABASE <database_name> TO ROLE PRIZM_ROLE;
No SELECT or IMPORTED PRIVILEGES required for metadata-only discovery.

​
Scoping & Object Inclusion

Can I exclude specific schemas or tables? Yes. Use the Include / Exclude wildcard patterns in the Asset Scope step of the connector wizard. Exclude rules take precedence over include rules when both match the same object. For example:
  • Include: ANALYTICS_DB.*
  • Exclude: ANALYTICS_DB.TEMP_*
Why is a table I expect not appearing in Prizm? Check that:
  1. The table’s database and schema match your include patterns
  2. The table is not matched by an exclude pattern
  3. PRIZM_ROLE has SELECT on that table (run SHOW GRANTS ON TABLE <table_name>)
  4. The Catalog job has completed at least once since the table was created
Does Prizm support Iceberg tables? Yes. Iceberg tables are detected via the IS_ICEBERG flag in INFORMATION_SCHEMA.TABLES. They are cataloged and monitored for freshness and volume. Column-level profiling requires the Iceberg table to be registered in Snowflake with accessible metadata.

​
Observability & Freshness

Why does Prizm show a freshness update when I only added a tag? Prizm reads freshness from INFORMATION_SCHEMA.TABLES.LAST_ALTERED. Snowflake updates this timestamp on any DDL operation, including tag assignments — even if no row data changed. This is Snowflake platform behaviour and cannot be filtered by Prizm. How does Prizm detect schema changes? Schema changes are detected by comparing LAST_DDL timestamps between Observability job runs. When a change is detected, Prizm fetches the current column list and diffs it against the stored snapshot. Added, removed, renamed, and type-changed columns are each reported as separate events. Why is FRESHNESS showing “NA” for my table? Freshness is derived from LAST_ALTERED. “NA” appears when:
  1. The table has never been altered since Prizm connected (no baseline timestamp)
  2. The Observability job has only run once (needs at least two data points)
  3. The table is a view — views do not track LAST_ALTERED in the same way

​
Write-Back & Data Safety

Does Prizm write data back to Snowflake? Prizm is read-only by default. The only write-back operation is optional bi-directional tag sync, which uses ALTER TABLE SET TAG statements. Enabling it requires the PRIZM_ROLE to hold TAG_ADMIN privileges and must be explicitly enabled in the connector feature settings. Does Prizm store or copy my Snowflake data? No. Prizm reads metadata and statistical aggregates (counts, min/max, means) — it does not copy row-level data. Profile jobs run SQL queries like SELECT COUNT(*), COUNT(DISTINCT col), MIN(col)... and store only the aggregate results.

​
Editions & Compatibility

What Snowflake editions does Prizm support? Prizm supports all Snowflake editions (Standard, Enterprise, Business Critical, Virtual Private). Column-level lineage via SNOWFLAKE.CORE.GET_LINEAGE requires Enterprise edition or above. Standard edition uses query log parsing for table-level lineage. Does Prizm support Snowflake on Azure / GCP as well as AWS? Yes. The connector works with all Snowflake deployment clouds. Use the account identifier format appropriate for your cloud: <account>.<region>.<cloud> (e.g., xy12345.east-us-2.azure).