Snowflake
Overview
Birdie integrates with Snowflake using read-only access. Two integration models are supported:
Reader Account (Snowflake Data Sharing) — recommended for shared-data environments
Direct OAuth Connection — recommended when Birdie connects directly to your main Snowflake account
Birdie can import data from Snowflake into Birdie for analytics, enrichment and reporting purposes, including:
Customers and accounts
Operational and reference tables
Feedback-related datasets exposed by the client
Because each Snowflake installation is unique, Birdie's team will work with your IT administrators to finalize details. This article explains how your Snowflake admin can generate and provide the credentials needed to enable the integration.
Schema requirements
All Birdie database connectors (Snowflake, Databricks, BigQuery, etc.) require one table or view per feedback type, following the Birdie schema definition.
Examples of feedback types:
nps
csat
review
social_media_post
support_ticket
Each feedback type must exist as a table or a view.
Birdie provides the detailed schema reference separately (same model as the S3 schema documentation).
Incremental Partition Column
Birdie uses a partition column to determine which rows to ingest on each run. Typical queries look like:
Requirements
The partition column must reflect when a row was added or last modified in the table, not when the original event occurred. For example:
LOAD_TIMESTAMPorUPDATED_AT(ETL/pipeline timestamp) — recommendedINSERTED_AT(row creation timestamp) — acceptable if the table is append-only
Why POSTED_AT is not sufficient
POSTED_AT is not sufficientUsing a business event timestamp like POSTED_AT can cause data gaps:
Historical updates missed: If a past row is updated (e.g., a ticket status changes), its
POSTED_ATremains in the past and Birdie will not re-ingest it.Pipeline timing gaps: If your ETL runs at specific times (e.g., every 6 hours), rows loaded between Birdie's query window and the ETL run may not appear until the next cycle. An
UPDATED_ATorLOAD_TIMESTAMPcolumn tied to the ETL timestamp ensures these rows are captured.
Recommendation
Add a LOAD_TIMESTAMP or UPDATED_AT column to your table that is set to CURRENT_TIMESTAMP() whenever a row is inserted or modified. Use this column as the partition_column when configuring the Birdie integration.
If your table is append-only and never updated, POSTED_AT is acceptable as the partition column.
Reader Account method
Overview
Birdie connects to a Snowflake Reader Account created via Snowflake Data Sharing. Birdie runs SELECT queries against databases instantiated from shared objects in that reader account.
This model is common when:
Your organization already uses provider-to-consumer data sharing
You want strict isolation between your production Snowflake account and external consumers such as Birdie
Requirements
Before starting:
Your account supports provider data sharing
You have
ACCOUNTADMIN(or equivalent) access on the reader accountThe provider account already exposes the necessary shares with the data Birdie will use
Setup in Snowflake
Grant privileges to the Birdie role
Warehouse usage:
Imported privileges on shared databases
Depending on how the share was configured, you may instead need to grant a shared database role to BIRDIE_READ. See: Snowflake GRANT ROLE
Integration via Direct OAuth Connection
Overview
In this model, Birdie connects directly to your main Snowflake account using OAuth instead of static passwords. This is recommended when:
You prefer SSO or OAuth-based access
You do not use Snowflake Data Sharing
You want Birdie to access native production schemas directly
Requirements
ACCOUNTADMIN (or equivalent) privileges in the main Snowflake account
Access to the Snowflake web console or CLI
The Snowflake connector has been enabled on the Birdie side
Setup in Snowflake
Share Connection Details with Birdie
To configure the integration, securely provide Birdie with the following information.
For Reader Account (Password auth):
For Direct OAuth:
connection_details
account
Yes
Snowflake account identifier, e.g. abc12345.us-east-1.
connection_details
warehouse
Yes
Snowflake warehouse name, e.g. BIRDIE_WH.
connection_details
role
Yes
Snowflake role, e.g. BIRDIE_READ.
connection_details.auth
method
Yes
Authentication mode: password (default) or oauth.
connection_details.auth
username
Yes
Snowflake username, e.g. BIRDIE_USER.
connection_details.auth
password
Password
Password for the Birdie user.
connection_details.auth
oauth_client_id
OAuth
OAuth client ID from the security integration.
connection_details.auth
oauth_client_secret
OAuth
OAuth client secret from the security integration.
data_source
database
Yes
Snowflake database name.
data_source
schema
Yes
Snowflake schema name.
data_source
table
Yes
Table or view name.
data_source
partition_column
No
Column for date filtering. Defaults to posted_at.
metadata
data_kind
Yes
The type(s) of data in the table, e.g. Support Ticket, NPS, CSAT, Review, Account.
Share credentials securely with the Birdie team. Never send credentials via email or unencrypted channels.
Security notes
Birdie never requires admin privileges for day-to-day operations
Access granted to Birdie is read-only, unless a specific export pipeline is explicitly configured
All credentials must be shared via a secure channel
OAuth is preferred over static passwords whenever possible
Data in scope
Once enabled, the Snowflake connector can import data from Snowflake into Birdie (for example, customer, account, or operational tables you expose to the Birdie role) and export Birdie data such as feedback records, areas, opportunities, and metrics back into Snowflake.
References
Last updated