Snowflake

Overview
How to connect
Automated checks
Useful links

DSALTA connects to Snowflake using read-only SQL to collect compliance evidence automatically. Data feeds into your Access accounts and Inventory pages.

DSALTA reads only. Every statement DSALTA runs against Snowflake is a read — SHOW USERS, SHOW DATABASES, SHOW WAREHOUSES, and a SELECT CURRENT_ACCOUNT() check at connection time. DSALTA has no code path that creates, modifies, or deletes anything in your account.

Read this before you run the setup SQL. Snowflake has no read-only privilege that permits SHOW USERS, so the setup below grants the DSALTA_RO role two account-level management privileges:

MANAGE GRANTS ON ACCOUNT — this is what makes the access review work, and it is not read-only. A role holding it can grant and revoke privileges anywhere in the account, including to itself.
MANAGE WAREHOUSES ON ACCOUNT — permits account-wide warehouse operations, used here only to enumerate warehouses for Inventory.

DSALTA never exercises either capability, but the role you create is capable of them, and anyone who can assume DSALTA_RO inherits that capability. Treat it as a privileged role: grant it only to the user who authorizes the connection, and audit it as you would any other account-level role. If your security policy forbids MANAGE GRANTS ON ACCOUNT, you can still connect: SHOW USERS then returns each user’s name only, and the access checks match that name against a person’s People username or the local part of their People email — a coarser review, covering everyone whose People username or email local part equals their Snowflake name.

DSALTA collects this integration’s data when you connect it — you can refresh it at any time with Sync from integrations on the Integrations page. The compliance checks below re-run once a day at 02:00 America/New_York.

What DSALTA reads

DSALTA reads the Snowflake user roster — names, emails, creation dates and enabled/disabled status, which land on your Access page (its Status column shows every synced account as Active, so confirm a disabled user in Snowsight rather than from that column); and your Snowflake resources, which appear on your Inventory page. DSALTA reads no role grants from SHOW USERS, so every user is listed with the role User.It calls these Snowflake endpoints:

/api/v2/statements (SQL statements API)

Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Snowflake environment.

Troubleshooting

Integration shows Disconnected

There is no Reconnect button. Open Integrations → Connected, click Manage on the Snowflake card, and check the Status tab — it shows either Connected and working properly or Connection issues detected. To restore a broken connection you must Disconnect and connect again, which permanently deletes the data and tests collected from Snowflake. Expect this at least every 90 days: Snowflake caps an OAuth refresh token at 90 days and then requires a fresh authorization. It also happens sooner if the DSALTA_RO grant is revoked or the OAuth security integration is dropped.

Data is not syncing

Verify the connected account still holds the permissions this integration requires. Then open Integrations in the DSALTA sidebar, stay on the Connected tab, and click Sync from integrations at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.

DSALTA requests these scopes: session:role:DSALTA_RO, refresh_token.Before you begin

An ACCOUNTADMIN who can register DSALTA as an OAuth client in your Snowflake account. Snowflake OAuth clients are per-account: someone has to run CREATE SECURITY INTEGRATION … TYPE = OAUTH, OAUTH_CLIENT = CUSTOM with the redirect URI DSALTA gives you, leave OAUTH_ISSUE_REFRESH_TOKENS = TRUE, and hand back the client id and secret from SYSTEM$SHOW_OAUTH_CLIENT_SECRETS. Without that, the sign-in window fails with an invalid-client error.

Start in DSALTA

Open Integrations in the DSALTA sidebar, find Snowflake, and click Connect to open the connect panel.

Create the DSALTA_RO role (run once, as ACCOUNTADMIN)

Snowflake’s OAuth blocks ACCOUNTADMIN/SECURITYADMIN, so DSALTA authorizes with a dedicated read-only role. In Snowsight, open a SQL worksheet and run this. The role must be named exactly DSALTA_RO, and replace <your_user> with the Snowflake user who will authorize:

USE ROLE ACCOUNTADMIN;

CREATE ROLE IF NOT EXISTS DSALTA_RO;
GRANT MANAGE GRANTS ON ACCOUNT TO ROLE DSALTA_RO;      -- access review: SHOW USERS
GRANT MANAGE WAREHOUSES ON ACCOUNT TO ROLE DSALTA_RO;  -- inventory: SHOW WAREHOUSES

GRANT ROLE DSALTA_RO TO USER <your_user>;

If you skip the MANAGE GRANTS ON ACCOUNT grant, the sync does not fail — it silently degrades. Any role can run SHOW USERS, but Snowflake returns only the name column and NULLs everything else unless the active role has MANAGE GRANTS on the account or OWNERSHIP of the user. You would get Access rows with a username and no email, no creation date and no enabled/disabled state, which the access checks then match by name instead — against a person’s People username, or the local part of their People email.

Create the role with exactly this spelling. DSALTA asks Snowflake for the scope session:role:DSALTA_RO, and Snowflake matches role names in that scope case-sensitively against the output of SHOW ROLES. Note that ACCOUNTADMIN, SECURITYADMIN, GLOBALORGADMIN and ORGADMIN can never be used instead — Snowflake blocks all four from OAuth by default and they cannot be removed from the blocked list.

Find your account hostname & connect

Click Connect — a secure window asks for your account hostname. It’s your Account/Server URL, e.g. your-account.snowflakecomputing.com (Snowsight: account menu → Account → Account/Server URL). Sign in as the user you granted DSALTA_RO to and authorize read-only access.In Snowsight, open the account selector, choose View account details, and copy the value in the Account/Server URL field of the dialog that opens.

Snowflake hands you a full URL that starts with https:// — paste only the host part, for example myorg-myaccount.snowflakecomputing.com. The connect window already supplies the https:// prefix.

Plan on re-authorizing at least every 90 days. Snowflake caps a custom OAuth client’s refresh token at 90 days (OAUTH_REFRESH_TOKEN_VALIDITY, default and maximum 7776000 seconds); when it expires Snowflake requires the whole authorization flow again. DSALTA has no Reconnect button, so the only path back is Disconnect and connect again — which deletes the Snowflake evidence and test history you have collected. Raising the validity is not possible; 90 days is the ceiling.

DSALTA 'Link Snowflake Account' window with a required Domain field showing an https:// prefix and the placeholder myorg-myaccount.snowflakecomputing.com, above a Connect button

Finish in DSALTA

Sign in in the secure window as the user you granted DSALTA_RO to and approve the read-only request; when the window closes DSALTA validates the session and completes the connection itself.

Once connected, Snowflake appears on the Connected tab and the checks below begin reporting after the first sync.

Each check below re-runs once a day, at 02:00 America/New_York, while this integration is connected. Click any check for step-by-step remediation guidance.

Check	Severity	What it verifies
User access to Critical System should be valid	Info	Checks that everyone with Snowflake access is an active employee on the People page.
Offboarded users should not have active access	High	Checks that offboarded employees no longer have active Snowflake access.

Topic	Link
Setup	Configuring Snowflake OAuth for custom clients
Setup	Snowflake SQL reference: SHOW USERS
General	Snowflake website
DSALTA	Connection error messages

Getting Connected

Identity Providers

Cloud Infrastructure

Code Repositories

Security & Monitoring

Databases

SaaS & Productivity

What DSALTA reads

Troubleshooting

​What DSALTA reads

​Troubleshooting

What DSALTA reads

Troubleshooting