Skip to main content

​
Connection & Authentication

There is no predefined limit on the number of connectors. However, once a Snowflake account is connected as a source, the same account cannot be onboarded multiple times — duplicate account connections are not allowed.
Prizm controls concurrency at the job orchestration layer. The settings below govern how many parallel queries run against your Snowflake warehouse at any time. Invalid or inactive sources are excluded from scheduling, reducing unnecessary load.For exact concurrency configuration details, contact your Prizm DevOps or platform team.
Yes. Prizm supports SSO and MFA for user login.
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).
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.
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.
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.
Use Vault to manage your Snowflake credentials when creating the connection. With Vault-backed connections, credential rotation happens entirely within your secrets manager — you update the secret in Vault, and Prizm automatically picks up the new credentials on the next job run without any changes to the connector configuration in Prizm. See the Use Vault option in the connection form when setting up authentication.

​
Permissions

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.
For catalog-only (no observability, quality, lineage, or performance):
No SELECT or IMPORTED PRIVILEGES required for metadata-only discovery.

​
Scoping & Object Inclusion

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_*
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
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

An alert is an automated signal that a monitored metric or quality check has breached its threshold. Alerts are generated by the observability engine without any human action — they fire when a value falls outside the expected range.An issue is a validated, actionable problem created from one or more related alerts. Issues are tracked work items that can be assigned, commented on, and resolved. The progression is:An alert escalates to an issue when one or more of the following is true: the affected asset is marked critical, multiple signal types fire simultaneously on the same dataset (e.g. volume drop + freshness delay + schema change), an SLA or SLO is breached, or an automation rule matches. Issues are the right place to track investigation and remediation; alerts are the raw signals.
Prizm uses time-series forecasting models to compute dynamic lower and upper thresholds for each metric automatically. The system:
  • Uses up to 100 recent historical run values as the lookback window per metric
  • Applies a Hampel filter (MAD-based, window 10, 3-sigma) to remove outliers before modeling, so transient spikes do not distort thresholds
  • Selects the forecasting model automatically based on the data’s characteristics:
  • A new metric spends its first more than 5 historical collection runs in Learning mode, accumulating a baseline, before alerts begin firing. This threshold counts collection runs, not elapsed time — a metric collected hourly reaches the end of Learning mode faster than one collected daily.
  • Alert priority (LOW, MEDIUM, HIGH, CRITICAL) is determined by how many standard deviations the current value falls outside the threshold band
  • Thresholds are recalculated after every run, so the model continuously adapts to changing patterns over time
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.
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.
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

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.
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

Prizm supports all Snowflake editions (Standard, Enterprise, Business Critical, Virtual Private) for catalog, profiling, and observability. Lineage is an Enterprise-and-above feature: it depends on SNOWFLAKE.CORE.GET_LINEAGE, which Standard edition does not expose. On a Standard-edition account, the Lineage graph will not populate — there is no query-log-based fallback. Upgrade to Enterprise edition or above to enable table- and column-level lineage.
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).

​
Connector Lifecycle

Deleting a source triggers an approval workflow based on your organization’s settings. Once approved, the source and all associated metadata are permanently deleted. The deletion cannot be undone after approval.
Existing metadata, quality scores, and alerts are retained while the connector is inactive. No new data is collected until the connector is re-enabled. If the connector is permanently deleted (after approval), all associated data is removed.
The platform supports both manual and scheduled refresh/re-sync operations. Triggering a manual scan runs the job immediately without affecting the configured schedule. Schedules for core job types (technical, operational, governance, performance, usage summary, compute metric) are created automatically when a source is configured. Custom metric schedules can be created manually. Any schedule update overrides the existing schedule and applies to all future executions.
The default data retention window for time-series observability data, quality score history, and query usage history is 90 days.

Troubleshooting

For connection errors, permission issues, and performance problems.

Glossary

For definitions of terms used in this FAQ.