Skip to main content

​
Connect Snowflake with Statisfy

The Snowflake integration lets you import data from your Snowflake warehouse into Statisfy. Author queries in the Statisfy settings UI, preview against your warehouse, and schedule them — sync product usage, account-level custom fields, person-level attributes, or custom objects. Snowflake uses the same self-serve configuration model as the other warehouse integrations. You can find the shared concepts — query types, account resolvers, transformers, schedules, configuration history — in Integration Concepts. This page focuses on what’s specific to Snowflake. Prerequisites:
  • Admin access to Statisfy
  • A Snowflake account with a dedicated user/role for Statisfy
  • The user must have USAGE on a warehouse and SELECT on the schemas/tables you want to sync
  • A credential — a Programmatic Access Token (PAT), a password, or a PKCS8 private key
New to the Snowflake side? Follow the Snowflake Service User Setup guide first — it walks through creating the service user, the network policy, and your PAT or key-pair in Snowsight, then you return here to connect.

​
What You Can Import

​
Authentication Methods

Snowflake supports three ways to authenticate: a PAT, a private key, or a password. A PAT is entered into the same Password field as a password (Snowflake treats it as one), so there’s no separate token input. Set up your chosen credential on the Snowflake side first with the Service User Setup guide.
A PAT is a scoped, expiring token that Snowflake generates for you. It’s the fastest path to connect and is fully clickable in Snowsight.Required credentials:
  • Account identifier (e.g., xy12345.us-east-1)
  • Username
  • The PAT, entered in the Password field (Snowflake accepts a PAT anywhere a password is expected — no special authenticator setting)
  • Default warehouse
  • Default database
  • Default schema
Generate the token following Step 4a of the Service User Setup guide. PATs expire (default 15 days, max 365), so set a rotation reminder.
For a TYPE = SERVICE user, Snowflake won’t generate a PAT until a network policy is attached to the user. Attach the policy first — see the setup guide.
Connect using username and password.Required credentials:
  • Account identifier
  • Username
  • Password
  • Default warehouse
  • Default database
  • Default schema
Suitable for trials or short-lived setups. For anything longer-lived, prefer a PAT (also entered in the Password field) or key-pair auth — both avoid storing a raw human password.

​
Set Up the Service User

Before connecting, create a dedicated read-only service user in Snowflake, restrict it to Statisfy’s egress IPs with a network policy, and issue a PAT or key-pair. The full walkthrough — mostly clickable in Snowsight — lives in a separate guide:

Snowflake Service User Setup

Create the role, warehouse, service user, network policy, and your PAT or key-pair credential, step by step.

​
Steps to Connect

  1. Log in to Statisfy.
  2. Navigate to Integrations → Admin Apps → Snowflake → Connect.
  3. Pick Private Key or Password authentication and fill in the fields:
    • Account — your Snowflake account identifier (host without .snowflakecomputing.com)
    • Username — the service user
    • Private Key / Password — the credential matching the method you chose. If you’re using a PAT, paste it into the Password field.
    • Default Warehouse / Database / Schema — used for queries that don’t fully qualify their objects
  4. Click Test Connection to confirm Statisfy can authenticate and run a no-op query.
  5. Once connected, Snowflake will appear as Connected on the Integrations page.

​
Configure Queries

Open Integrations → Snowflake → Settings to:
  • Browse databases, schemas, and tables the service user can see, with column types
  • Author queries using Snowflake SQL with autocomplete and a preview pane
  • Map results to Statisfy accounts (via Statisfy account ID, CRM ID, organization ID, email domain, account name, or any custom field) and to fields, metrics, or custom objects
  • Apply column transformers to reshape values before they’re written
  • Set the cadence — daily, weekly, monthly, or a sub-day interval (HOURLY through TWELVE_HOURS)
  • Run a one-off sync on demand
Each saved query is one of three types — product_usage, custom_field, or custom_object. See Query types and Account resolvers for the shared model.

​
Snowflake-Specific Notes

  • Fully qualify objects across databases. If a query references a table outside the default database / schema, qualify it explicitly: OTHER_DB.SCHEMA.TABLE.
  • Date placeholders. Use {START_DATE} / {END_DATE_SQL} to keep queries incremental. Snowflake’s DATE_TRUNC(), DATEADD(), and TO_DATE() work well with these placeholders.
  • Warehouse cost. Each query consumes warehouse credits. Use a small (XSMALL/SMALL) warehouse with AUTO_SUSPEND = 60 to minimize idle cost, and rely on Snowflake result caching for repeat scans.
  • Case sensitivity. Snowflake uppercases unquoted identifiers. Quote columns and tables if your warehouse uses mixed-case identifiers, otherwise stick to uppercase consistently in the query.

​
Account Matching

Rows that don’t resolve to an existing Statisfy account are skipped. For CRM ID resolvers, make sure your CRM integration has synced the matching accounts first.
For custom_field queries that target people instead of accounts, configure a person resolver (email column, optionally name) — Statisfy will upsert the person record by email.

​
Sync Behavior

Scheduled Jobs:
  • Each saved query runs on its own cadence.
  • The first run after connecting is a bootstrap covering the last 30 days; subsequent runs cover only the active window for the cadence.
  • Self-serve configuration takes precedence over any built-in fallback set up by support.
Error Handling:
  • Per-query errors are logged but do not block other queries from running.
  • Invalid rows within a query are skipped and reported in the job audit log.

​
Network Access

If your Snowflake account uses network policies to restrict access by IP, allow Statisfy’s egress IPs:
You can configure this with a clickable Snowsight walkthrough — see Steps 2–3 of the Service User Setup guide — or via CREATE NETWORK POLICY and assign the policy to your service user.
A network policy isn’t just for IP restriction: a TYPE = SERVICE user must have a network policy attached before Snowflake will let it generate or use a PAT.

​
Security

  • Credentials are stored encrypted in Google Cloud Secret Manager.
  • Private key authentication is recommended for production.
  • All connections use TLS.
  • Queries authored in the Settings page are read-only — Statisfy validates each query and rejects DDL/DML before save.
  • Access is scoped to whatever the service user’s role can see — grant only the schemas you want Statisfy to read.

​
Troubleshooting

PAT auth:
  • Confirm the token was pasted into the Password field and hasn’t expired (default 15 days, max 365) — regenerate if needed
  • For a TYPE = SERVICE user, confirm a network policy is attached and includes Statisfy’s egress IPs — the token won’t authenticate without it
  • If you attached an authentication policy, confirm its AUTHENTICATION_METHODS includes 'PROGRAMMATIC_ACCESS_TOKEN'
Password auth:
  • Confirm the account identifier is correct (host minus .snowflakecomputing.com)
  • Confirm the password hasn’t expired or rotated
Private key auth:
  • The key must be in PEM format with PKCS8 encoding
  • Confirm the passphrase is correct (if the key is encrypted)
  • Confirm the public key has been assigned to the service user (DESC USER ... ; → RSA_PUBLIC_KEY)
  • Confirm the service user’s role has USAGE on the database and schema and SELECT on the tables
  • INFORMATION_SCHEMA and system schemas are intentionally hidden
  • If you recently granted access, the picker may need to be reloaded
  • Statisfy validates queries against the Snowflake SQL dialect — vendor-specific functions from other warehouses will be flagged
  • DDL (CREATE, DROP) and DML (INSERT, UPDATE, DELETE, MERGE) are rejected — only read-only queries are allowed
  • Check the validation error for the offending function or syntax
  • Verify the resolver column contains values that exist in Statisfy
  • For CRM ID resolvers, confirm your CRM integration has synced the matching accounts
  • Try a different resolver (switch from account name to email domain) if matching is unreliable
  • Add a regex_extract or strip_prefix transformer if the column contains the right ID with extra characters
  • Drop the warehouse size to XSMALL for read-only sync queries
  • Lower the cadence to DAILY so each run scans a smaller window
  • Use {START_DATE} / {END_DATE_SQL} to keep queries incremental rather than scanning the full table

​
Need Help?

For initial setup, query design, or troubleshooting, contact support@statisfy.com.