Integrating a Snowflake Table on Clarisights

Connect a Snowflake table or view as a read-only data source so data living in your Snowflake warehouse — internal attribution, LTV, finance, or any other governed dataset — can be blended into your Clarisights reporting alongside paid channels.

This integration is technical and requires admin access on Snowflake to manage roles, grants, and credentials. Share this article with your data team or Snowflake administrator.

At a glance

Connector type Data warehouse (read-only)

Authentication RSA key-pair (recommended); Username + Password (beta, on request); OAuth (beta, on request)

Permissions needed USAGE on the warehouse, database, and schema; SELECT on the table or view

Object support Tables and views (both first-class)

Refresh cadence Set per pipeline

Limited rollout No

Authentication options

RSA key-pair (recommended)

Clarisights generates the RSA key-pair and shares the public key with you. The private key never leaves Clarisights' infrastructure. You attach the public key to a Snowflake user with ALTER USER <user> SET RSA_PUBLIC_KEY = '<public-key>'. This is the recommended option for all production connections.

Username + Password (beta)

Available on request. Recommended only for short-lived testing — not for ongoing production use.

OAuth (beta)

Available on request. Recommended only when your identity provider requires OAuth and key-pair is not an option.

Setting up the connection

Step 1 — Request a public key from Clarisights

Reach out to your CSM or write to support@clarisights.com to request the integration. We will generate an RSA key-pair on our side and share the public key with you in this format:


-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhk...
-----END PUBLIC KEY-----

The corresponding private key never leaves Clarisights.

Step 2 — Create a Snowflake role and service user

In Snowflake, run the following as ACCOUNTADMIN (substitute your warehouse, database, schema, and table or view names). The default user name is SERVICE_ACCOUNT_CLARISIGHTS; you can rename it if your conventions require — just share the chosen name with us in Step 4.


USE ROLE ACCOUNTADMIN;

CREATE ROLE IF NOT EXISTS clarisights_query;

CREATE USER IF NOT EXISTS service_account_clarisights
    PASSWORD = '<TEMP_PASSWORD>';

GRANT ROLE clarisights_query TO USER service_account_clarisights;

ALTER USER service_account_clarisights
    SET DEFAULT_ROLE = clarisights_query
    DEFAULT_WAREHOUSE = '<WAREHOUSE>';

GRANT USAGE ON WAREHOUSE <WAREHOUSE> TO ROLE clarisights_query;
GRANT USAGE ON DATABASE <DATABASE> TO ROLE clarisights_query;
GRANT USAGE ON SCHEMA <DATABASE>.<SCHEMA> TO ROLE clarisights_query;

-- For a table:
GRANT SELECT ON TABLE <DATABASE>.<SCHEMA>.<OBJECT> TO ROLE clarisights_query;

-- Or for a view:
GRANT SELECT ON VIEW <DATABASE>.<SCHEMA>.<OBJECT> TO ROLE clarisights_query;

Permission denied on object → the role is missing USAGE at the warehouse, database, or schema level, or SELECT on the specific table or view. Re-run the grants above for the failing object.

Step 3 — Attach the public key to the Snowflake user

Attach the public key Clarisights shared with you in Step 1 (paste the body of the key, without the BEGIN/END header lines):


ALTER USER SERVICE_ACCOUNT_CLARISIGHTS
    SET RSA_PUBLIC_KEY='MIIBIjANBgkqhk...';

Authentication failed → the public key was not attached, was attached to the wrong user, or whitespace/line breaks were introduced when pasting. Snowflake user names are case-sensitive on lookup — confirm the user exists and re-run the ALTER USER statement.

Step 4 — Share the connection details with Clarisights

Send the following to your CSM. We use these to configure the channel on our side. See Connection details exchange below for the full list.

Warehouse suspended / unable to start → the warehouse must be running when we query, or set to AUTO_RESUME = TRUE so Snowflake wakes it on demand. A suspended warehouse without auto-resume will fail.

Step 5 — Allow-list Clarisights' outbound IPs (if you use a network policy)

If your Snowflake account enforces a network policy, add Clarisights' outbound IPs to the allow-list. Your CSM will share the current IP list — keep it in sync if you receive updates.

Step 6 — Configure dimensions and metrics with your CSM

Once Clarisights validates the connection, you'll work with your CSM to map each Snowflake column to a Clarisights dimension or metric. The mapping happens entirely on our side; no further changes are needed in Snowflake.

Connection details exchange

You provide to Clarisights

Clarisights provides to you

Account URL (e.g. xy12345.eu-central-1.snowflakecomputing.com)

RSA public key (for key-pair authentication)

Warehouse name

Service-account user name (default SERVICE_ACCOUNT_CLARISIGHTS; you may rename it)

Database name

Outbound IP addresses (for network-policy allow-listing)

Schema name

Table or view name

Snowflake user name with the required grants

Confirmation that ALTER USER ... SET RSA_PUBLIC_KEY has been executed with the public key we shared

What we read

Clarisights reads from a single Snowflake object per channel — either a table or a view. Both are first-class: point us at whichever fits your workflow. We run a SELECT against the object exactly as configured and ingest the rows we receive.

If you need to filter, join, deduplicate, or otherwise transform the data before it lands in Clarisights, do that in a view on your side. We read what's there as-is.

Connector specifics

Warehouse must be running. The warehouse you point us at must be running when the pipeline executes, or configured with AUTO_RESUME = TRUE so Snowflake wakes it on demand. A suspended warehouse without auto-resume will cause the pull to fail.
Transformations belong in a view on your side. Clarisights reads what's in the table or view as-is. If you need cleanup, joins, or pre-aggregation, materialize that into a view we can read.
Network policy allow-listing. If your Snowflake account uses a network policy, Clarisights' outbound IPs must be on the allow-list or every connection attempt will be rejected.

Limitations & known constraints

One object per channel. Each Snowflake channel maps to a single table or view. Connect multiple channels to bring in multiple objects.
Read-only. Clarisights only runs SELECT queries against the objects you grant access to.
Warehouse compute. Queries run on your Snowflake warehouse and consume credits on your account. Right-size the warehouse for the data volume.
Query timeout. Long-running queries that don't return within Snowflake's configured timeout will fail; partition or pre-aggregate upstream if your object is too large to scan in one pass.
Schema shape. Each object should expose at least one date column, at least one numeric column for metrics, and at least one string column for dimensions so it can be modelled in Clarisights.

Operating notes

Refresh cadence is set per pipeline at configuration time. Talk to your CSM to change it.
Lookback: each pull re-reads rows in the configured lookback window so late-arriving data is captured.
Multi-object: connect one Snowflake channel per table or view. Objects across multiple databases or schemas are supported, provided the role has the right grants.
Credential rotation: to rotate the key, ask Clarisights to generate a new public key, then run ALTER USER ... SET RSA_PUBLIC_KEY = '<new-key>'. Snowflake also supports RSA_PUBLIC_KEY_2 for zero-downtime rotation — set the new key as RSA_PUBLIC_KEY_2, confirm Clarisights is using it, then promote it to RSA_PUBLIC_KEY.
Network policy: keep Clarisights' outbound IP list in sync with your network policy whenever we notify you of changes.

Need help?

When contacting support from the in-app messenger, please include:

The integration name and account ID (Integrations → Channel)
The exact error message or screenshot
The step where the issue occurred
When the issue started