For the complete documentation index, see llms.txt. This page is also available as Markdown.

Create Snowflake User and Privileges

In this section, we'll take care of having the prerequisites for creating a Snowflake - Seemore integration.

This page walks you through creating the Snowflake role, user, and privileges that SeeMore Data needs to connect to your account.

Two ways to set this up:

  • Step by step — follow the sections below to create and grant each piece individually. The Core Setup Script combines the essential steps into a single block.

  • All at once — to enable every capability (core plus all optional add-ons) in one run, jump to the Complete Setup Script (All Permissions) at the end of this page.

What you'll set up on this page:

  1. Core integration — a role, a user (key-pair authentication), and the privileges SeeMore Data needs to read metadata and monitor usage.

  2. Optional capabilities — extra procedures and grants that unlock specific features: streams & dynamic-table monitoring, materialized-view & inbound data-sharing listing, auto-clustering recommendations, Cortex Code cost controls, warehouse-parameter reading for warehouse automations, and replication-group details.

  3. Account-level options — enabling ORGADMIN for organization-wide observability, and allowlisting the SeeMore Data IPs.

Create a role

Create a role in Snowflake using the following commands:

-- Switch to the ACCOUNTADMIN role to perform administrative tasks such as creating warehouses.
USE ROLE ACCOUNTADMIN;
CREATE ROLE IF NOT EXISTS seemore_user_role;
GRANT OPERATE, USAGE ON WAREHOUSE "<warehouse_name>" TO ROLE seemore_user_role;
  • Replace <warehouse_name> with the default warehouse to use when running the Seemore snowflake "metadata fetcher".

Create a user

SeeMore Data connects to Snowflake using key-pair authentication. You'll generate an RSA key pair, create the user with the public key, and later provide the private key to SeeMore Data when you set up the integration.

Key-pair authentication is the recommended and supported method. It avoids storing a password on the connection and isn't affected by password-rotation policies.

1. Generate the private key

Open a terminal window and generate a private key. You can generate either an encrypted or an unencrypted version.

To generate an unencrypted version, use:

To generate an encrypted version, use the following command, which omits -nocrypt:

2. Generate the public key

3. Create the user with the public key

Create the user and assign the public key you just generated. Replace <public_key> with the contents of rsa_key.pub without the -----BEGIN PUBLIC KEY----- / -----END PUBLIC KEY----- lines, and replace <warehouse_name> with your warehouse.

If the user already exists, attach the key instead with:

For more details, see the official Snowflake key-pair authentication documentation.

Grant role to user

To grant the user_role to the new user:

Grant Privileges

In order to fetch metadata from snowflake, Seemore needs access only to SNOWFLAKE using GRANT IMPORTED PRIVILEGES.

Core Setup Script

This script covers the core integration — creating a dedicated warehouse for Seemore, establishing roles, creating the user with key-pair authentication, and assigning the necessary privileges for operations and monitoring. Replace <public_key> with the contents of your rsa_key.pub (without the -----BEGIN/END PUBLIC KEY----- lines) — see Create a user for how to generate the key pair. If you don't need a dedicated warehouse, comment out the CREATE WAREHOUSE block and replace seemore_warehouse with your own warehouse name.

This is enough to connect SeeMore Data and start monitoring. It does not include the optional capabilities further down this page. To provision the core integration and every optional add-on in a single run, use the Complete Setup Script (All Permissions) at the end of this page.

Monitoring Additional Snowflake Services

Tune Warehouses Automations

To allow Seemore to analyze, optimize, and implement the best configurations for your warehouses, please grant the necessary permissions. These permissions are also needed for Seemore to access query statistics via get_query_operator_stats and to perform smart pulse, auto-shutdown, and auto-scaling operations.

Streams, Dynamic tables & Materialized Views

A single list_object procedure serves every object type Seemore lists — streams, dynamic tables, materialized views, inbound data-sharing providers, replication groups, and warehouse parameters — selected by the OBJECT_KEY argument. Deploying it once enables all of them.

  • Create (or use) a dedicated database and schema to house the procedure:

  • Grant the necessary privileges to seemore_user_role so it can execute the procedure and view the results:

    (Adjust privileges if additional permissions are required by your security model.)

  • Use a role with `ACCOUNTADMIN` to create or replace the procedure. This high-level role is needed to grant the procedure enough access to list all streams.

  • Create (or replace) the stored procedure with EXECUTE AS OWNER. This setting ensures the procedure runs with the privileges of the owner (the role that created it). That way, even if the caller’s role does not have the privileges to see all streams directly, the procedure can still return the entire list:

Auto clustering recommendations

Permissions to Auto Clustering monitoring and recommendations

By creating the below procedures and give Seemore the access to it we will be able to help you cluster your tables in a more efficient way and also improve Snowflake's auto-clustering feature, Without the need of exposing data at all.

  • First, create the Seemore database and schema if not exists:

  • It is important to create the following procedures using `ACCOUNTADMIN` role. This high-level role is needed to grant the procedure access to all the tables clustering information.

  • GET_CLUSTERING_INFO - Create a procedure that gives Seemore an ability to access snowflake clustering information method, which allows us optimizing our recommendation of clustering columns candidates, based on actual cardinality stats of the tables.

  • GET_CLUSTERING_COST_ESTIMATE Create a procedure that gives Seemore an access to auto clustering cost estimate method, So Seemore can use it for estimating the cost of turning on auto clustering based on out recommendations.

Cortex Code Cost Controls

Snowflake's Cortex Code is an AI assistant available in Snowsight and the Snowflake CLI. Each interaction consumes credits, and without limits, usage can grow quickly. Seemore can help you manage Cortex Code costs by setting daily estimated credit usage limits per user across both surfaces (CLI and Snowsight).

Limits are tracked over a rolling 24-hour window. When a user's estimated usage reaches the configured threshold, access is blocked for that surface until usage drops below the limit.

Limit value
Behavior

-1 (default)

No limit — unlimited access

0

Access is blocked entirely

Positive number

Access is blocked when estimated credit usage exceeds this value

Limits can be applied at the account level (all users) or at the user level (overrides the account-level setting for that user).

The Seemore database and schema must already exist. If you haven't created them yet, refer to the setup in the Streams, Dynamic tables & Materialized Views section above.

  • It is important to create the following procedures using ACCOUNTADMIN role. This high-level role is needed because ALTER ACCOUNT and ALTER USER parameter changes require elevated privileges.

The script below creates four procedures:

  • SET_CORTEX_CODE_LIMIT — Set a daily estimated credit usage limit at the account or user level.

  • UNSET_CORTEX_CODE_LIMIT — Remove a previously set limit, restoring the default (unlimited) behavior.

  • GET_CORTEX_CODE_ACCOUNT_LIMITS — Retrieve the current Cortex Code credit limits at the account level.

  • GET_CORTEX_CODE_USER_LIMITS — Retrieve the current Cortex Code credit limits for a specific user.

Replication Cost Detail

Snowflake bills replication — both the compute and the data transfer — to the account that holds the secondary copy (the target account), not to the account you replicate from. To see replication cost broken down by replication group, with bytes transferred and refresh history (including failed refreshes, which Snowflake still charges), connect each target account to SeeMore Data using the setup on this page.

The cost, bytes, and refresh history need no extra grant: IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE from Grant Privileges already covers them.

To also show whether each group is a primary or a secondary, and which account it replicates from, deploy the latest list_object procedure in each target account. It lists replication and failover groups with the 'replication_groups' key, and because it runs as its owner it sees every group, so no per-group grant is needed. If you already deployed list_object, re-run its CREATE OR REPLACE to pick up the new key.

To see the full replication bill across all your accounts — including target accounts you haven't connected yet — also enable ORGADMIN.

Warehouse Parameters

Seemore reads per-warehouse parameters — such as MAX_CONCURRENCY_LEVEL and statement timeouts — to power its warehouse automations (smart pulse, auto-shutdown, auto-scaler). Reading these directly with SHOW PARAMETERS IN WAREHOUSE requires elevated privileges on each warehouse that seemore_user_role doesn't have.

These parameters are returned by the same list_object procedure documented in Streams, Dynamic tables & Materialized Views — call it with the 'warehouse_parameters' key and it returns the parameters for every warehouse in a single call, tagged with the warehouse each row belongs to.

No extra procedure is needed here. Deploy the list_object procedure from the Streams, Dynamic tables & Materialized Views section (its latest version includes the 'warehouse_parameters' branch) and warehouse-parameter reading works automatically.

Enable ORGADMIN

To unlock organization-level observability and contract observability in Seemore, the Snowflake account must be attached to the ORGADMIN role. This is also what lets SeeMore Data show your full replication bill, which Snowflake charges to the target accounts.

  1. Log in to your Snowflake organization account with a user that has the ORGADMIN role.

  2. Navigate to Admin → Accounts.

  3. Click the ... menu on the account you want to connect to Seemore.

  4. Select Enable ORGADMIN.

Enable ORGADMIN on a Snowflake account
Enable ORGADMIN from the Accounts page

Alternatively, you can enable it via SQL:

Allowlist the Seemore IP

If you are using the IP allowlist in your Snowflake instance, you must add the Seemore IP to the allowlist.

(If you are not using the IP Allowlist in your Snowflake instance, you can skip this step.)

Complete Setup Script (All Permissions)

This is the all-in-one version of everything on this page. Run it as ACCOUNTADMIN to provision the role, user, warehouse, core monitoring privileges, and all optional capabilities — streams / dynamic-table / materialized-view listing, auto-clustering recommendations, Cortex Code cost controls, and replication-group details — in a single step.

Use this if you want to enable every SeeMore Data feature at once. If you only need the basic integration, use the Core Setup Script above instead and add optional capabilities later.

Before running, replace:

  • <public_key> — the contents of your rsa_key.pub (without the -----BEGIN/END PUBLIC KEY----- lines). See Create a user for how to generate the key pair.

  • seemore_warehouse — keep it to create a dedicated warehouse, or replace it with an existing warehouse name and comment out the CREATE WAREHOUSE block.

Optional blocks are labeled inside the script — comment out any capability you don't want to enable. Enabling ORGADMIN is a separate step (see Enable ORGADMIN) because it uses a different Snowflake role.

Last updated