Skip to main content

General Integrations

The following AI Incident Assistant integrations are available in the Other category: 

Snowflake

Beta integration

This integration is currently in beta release status.

Beta integrations are still being tested, but can be enabled by any customer. Core connectivity is stable, but the integration may receive updates based on user feedback.

The Biggy Snowflake integration lets Biggy work with business data, observability exports, and ITSM replicas by querying and searching your warehouse data.

Biggy connects to Snowflake with a dedicated read-only service user and queries your warehouse with SQL, plus Cortex Analyst and Cortex Search when those services are available.  Snowflake blocks passwords for service users, so users authenticate with a key-pair (recommended) or a Programmatic Access Token (PAT).

To set up the integration, first run the setup SQL in Snowflake to create the service account, then configure the connection fields in Biggy.

Set Up the Snowflake Service Account

To configure a service account to manage Biggy access to Snowflake, Run the following SQL in Snowflake as ACCOUNTADMIN (or a delegated admin). The role is the primary security boundary, so grant the account access only to the databases Biggy should see.

Create the read-only role, warehouse, and grants

Create a BIGGY_READONLY role and a dedicated BIGGY_WH warehouse, then grant the role read-only access to each database that Biggy may query. 

In the code below, repeat the database grant lines for every database you want Biggy to see. Granting FUTURE keep new objects readable as your schema evolves.

CREATE ROLE IF NOT EXISTS BIGGY_READONLY;

-- Dedicated XS warehouse keeps Biggy's compute cost bounded and visible.
CREATE WAREHOUSE IF NOT EXISTS BIGGY_WH
  WAREHOUSE_SIZE = XSMALL AUTO_SUSPEND = 60 AUTO_RESUME = TRUE INITIALLY_SUSPENDED = TRUE;
GRANT USAGE ON WAREHOUSE BIGGY_WH TO ROLE BIGGY_READONLY;

-- Repeat per database Biggy should see. FUTURE grants keep new objects readable.
GRANT USAGE ON DATABASE <db> TO ROLE BIGGY_READONLY;
GRANT USAGE ON ALL SCHEMAS IN DATABASE <db> TO ROLE BIGGY_READONLY;
GRANT SELECT ON ALL TABLES IN DATABASE <db> TO ROLE BIGGY_READONLY;
GRANT SELECT ON ALL VIEWS IN DATABASE <db> TO ROLE BIGGY_READONLY;
GRANT USAGE ON FUTURE SCHEMAS IN DATABASE <db> TO ROLE BIGGY_READONLY;
GRANT SELECT ON FUTURE TABLES IN DATABASE <db> TO ROLE BIGGY_READONLY;
GRANT SELECT ON FUTURE VIEWS IN DATABASE <db> TO ROLE BIGGY_READONLY;

Create the service user

Create the BIGGY_SVC service user and grant it the read-only role. 

CREATE USER IF NOT EXISTS BIGGY_SVC
  TYPE = SERVICE
  DEFAULT_ROLE = BIGGY_READONLY
  DEFAULT_WAREHOUSE = BIGGY_WH
  COMMENT = 'Biggy read-only integration user';
GRANT ROLE BIGGY_READONLY TO USER BIGGY_SVC;

-- Account-side runaway-query bound (Biggy also enforces its own timeout).
ALTER USER BIGGY_SVC SET STATEMENT_TIMEOUT_IN_SECONDS = 300;

The statement timeout sets an account-side bound on runaway queries. Biggy also enforces its own timeout.

Set up key-pair authentication (Recommended)

Generate an RSA key-pair locally, then register the public key on the service user. 

Save this key somewhere referenceable. When you configure the integration, you will paste the full .p8 private key contents, including the BEGIN and END lines, into the Private Key (PEM) field. 

Key-pair credentials do not expire, and Biggy signs a short-lived JWT for each request. To rotate, generate a fresh pair, run ALTER USER BIGGY_SVC ROTATE KEY PAIR BIGGY_KEY PUBLIC_KEY = '<new_public_key_body>', and update the Private Key field in Biggy. The old key stays valid for 24 hours by default.

openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out biggy_snowflake_key.p8 -nocrypt
openssl rsa -in biggy_snowflake_key.p8 -pubout -out biggy_snowflake_key.pub

-- Paste the .pub contents WITHOUT the BEGIN/END lines:
ALTER USER BIGGY_SVC ADD KEY PAIR BIGGY_KEY PUBLIC_KEY = '<public_key_body>';

Set up a programmatic access token

A Programmatic Access Token (PAT) is simpler to issue, but it expires (365-day maximum), and Snowflake requires the service user to sit under a network policy that allows Biggy's egress IPs. 

The following SQL creates a dedicated BIGGY_ADMIN namespace for the network objects, builds the network rule and policy, applies the policy to the service user, and issues the token. 

Copy the token secret when Snowflake displays it and paste it into the Programmatic Access Token field in Biggy.

-- PATs require the service user to sit under a network policy.
-- Network rules are schema-level objects: create one in a dedicated Biggy namespace and
-- reference its FULLY QUALIFIED name from the account-level policy (unqualified names depend
-- on the worksheet's current database/schema and fail on a fresh session).
-- CREATE OR ALTER is the idempotent form (CREATE NETWORK RULE has no IF NOT EXISTS).
-- Re-running the rule/policy lines REPLACES VALUE_LIST and ALLOWED_NETWORK_RULE_LIST with
-- Biggy's current egress IPs; these objects are Biggy-owned -- do not share them.
CREATE DATABASE IF NOT EXISTS BIGGY_ADMIN;
CREATE SCHEMA IF NOT EXISTS BIGGY_ADMIN.NETWORK;
CREATE OR ALTER NETWORK RULE BIGGY_ADMIN.NETWORK.BIGGY_INGRESS_RULE
  TYPE = IPV4 MODE = INGRESS
  VALUE_LIST = ('3.131.207.50/32', '3.139.161.178/32', '3.132.123.188/32');
CREATE OR ALTER NETWORK POLICY BIGGY_ACCESS_POLICY
  ALLOWED_NETWORK_RULE_LIST = ('BIGGY_ADMIN.NETWORK.BIGGY_INGRESS_RULE');
ALTER USER BIGGY_SVC SET NETWORK_POLICY = 'BIGGY_ACCESS_POLICY';

-- Issue the PAT once. If BIGGY_PAT already exists, ADD fails -- rotate instead:
-- ALTER USER BIGGY_SVC ROTATE PROGRAMMATIC ACCESS TOKEN BIGGY_PAT;
ALTER USER BIGGY_SVC ADD PROGRAMMATIC ACCESS TOKEN BIGGY_PAT
  ROLE_RESTRICTION = 'BIGGY_READONLY' DAYS_TO_EXPIRY = 365;

To refresh Biggy's egress IPs, re-run only the network-rule and policy lines. Do not re-run ADD PROGRAMMATIC ACCESS TOKEN if BIGGY_PAT already exists. Rotate it instead with ALTER USER BIGGY_SVC ROTATE PROGRAMMATIC ACCESS TOKEN BIGGY_PAT, then update the token in Biggy.

Grant Corex Analyst and Cortext Search

If your account has semantic views or Cortex Search services, you can grant them to the BIGGY_READONLY role. Once granted access, Biggy discovers and uses them automatically, with no extra configuration.

Grant Corex Analyst and Cortext Search

If your account has semantic views or Cortex Search services, you can grant them to the BIGGY_READONLY role. Once granted access, Biggy discovers and uses them automatically, with no extra configuration.

Grant CORTEX_ANALYST_USER for REST access, then add per-view or per-service grants as needed.

 -- Cortex Analyst REST access for the role (SNOWFLAKE.CORTEX_USER also works, but is broader): GRANT DATABASE ROLE SNOWFLAKE.CORTEX_ANALYST_USER TO ROLE BIGGY_READONLY; -- Per semantic view: SELECT to query (owner's rights cover the base tables), -- REFERENCES so discovery can inspect the structure. GRANT SELECT, REFERENCES ON SEMANTIC VIEW <db>.<schema>.<view> TO ROLE BIGGY_READONLY; -- Per Cortex Search service (the role also needs USAGE on its database and schema): GRANT USAGE ON DATABASE <db> TO ROLE BIGGY_READONLY; GRANT USAGE ON SCHEMA <db>.<schema> TO ROLE BIGGY_READONLY; GRANT USAGE ON CORTEX SEARCH SERVICE <db>.<schema>.<service> TO ROLE BIGGY_READONLY;
-- Cortex Analyst REST access for the role (SNOWFLAKE.CORTEX_USER also works, but is broader):
GRANT DATABASE ROLE SNOWFLAKE.CORTEX_ANALYST_USER TO ROLE BIGGY_READONLY;

-- Per semantic view: SELECT to query (owner's rights cover the base tables),
-- REFERENCES so discovery can inspect the structure.
GRANT SELECT, REFERENCES ON SEMANTIC VIEW <db>.<schema>.<view> TO ROLE BIGGY_READONLY;

-- Per Cortex Search service (the role also needs USAGE on its database and schema):
GRANT USAGE ON DATABASE <db> TO ROLE BIGGY_READONLY;
GRANT USAGE ON SCHEMA <db>.<schema> TO ROLE BIGGY_READONLY;
GRANT USAGE ON CORTEX SEARCH SERVICE <db>.<schema>.<service> TO ROLE BIGGY_READONLY;

Configure the Biggy Snowflake Integration

To configure the Biggy Snowflake integration, click Add Instance and populate the following fields:

Field

Description

Example

Instance Name

A name to identify this Snowflake (or warehouse)instance in the list. 

US East Production

Authentication Method

Choose how to authenticate with this integration. The following methods are available: 

  • Key-pair (recommended) - Biggy signs a short-lived JWT per request using an RSA key-pair. The credential does not expire, and you can rotate it anytime. 

  • Programmatic Access Token (PAT) - Simpler setup, but the token expires (365-day maximum), and the service user must be under a network policy that allows Biggy's egress IPs.

Account URL

Base URL of your Snowflake account.

https://<orgname>-<account>.snowflakecomputing.com

Credentials

Key-pair authentication method: enter the Service Username (BIGGY_SVC), paste the full .p8 private key contents into the Private Key (PEM) field, and enter the Private Key Passphrase only if the key is encrypted. 

Programmatic Access Token authentication method, paste the token secret into the Programmatic Access Token field.

Account Identifier

Your Snowflake account identifier in the form <orgname>-<account>, with no domain. 

MYORG-MYACCOUNT

Warehouse

The warehouse Biggy uses for queries.

BIGGY_WH

Role

The read-only role Biggy uses for queries. 

BIGGY_READONLY

Default Database (Optional)

The default database for queries. 

ANALYTICS

Default Schema (Optional)

The default schema for queries. 

PUBLIC

Deployment Type

Select whether your Snowflake account is Cloud or On-Prem. Certain integrations have endpoints that work only with one deployment type. Selecting the correct option automatically applies the right guardrails to the Biggy agents. 

Note: On-prem integrations can connect via the Relay Client, enabling secure communication with infrastructure behind your firewall.

Routing Instructions (Optional)

Describe when this Snowflake instance should be used. Routing instructions are necessary only when multiple Snowflake instances are configured.

This is the US East production account. Use for any queries about US-based production services.

System/Schema Nuances

List any special field mappings, naming conventions, custom tables/fields, or other knowledge that helps Biggy more effectively interact with your tool. 

We highly recommend configuring this field, as it allows you to enter organization-specific information necessary for more accurate and consistent results. For example, you can include which databases and schemas contain which data, what the key tables and columns mean, and any semantic views or Cortex Search services that Biggy should prefer. 

You can also click Generate with AI to draft these notes.

After entering the fields, click Verify Connection to test your credentials. Set the Enable toggle, and click Save All Instances.

Multiple accounts

You can connect multiple Snowflake accounts to BigPanda. For example, to connect production and development accounts, or one per region. Each account should be added to only one instance, each with a distinct name and description.

Network policies and private connectivity

Biggy reaches Snowflake over the public account URL from three egress IPs: 3.131.207.50, 3.139.161.178, and 3.132.123.188. If your account enforces network policies, allow these IPs. The Programmatic Access Token SQL above does this for you.

PrivateLink-only accounts can route through a Biggy Remote Connection instead of the public URL. Set Deployment Type to On-Prem on the instance, save, then assign the instance to a relay client under Remote Connections in the Configuration area. Use your PrivateLink account URL.

In this section: