DEV Community: Krishna Tangudu

Ask Your Snowflake Account Anything — Build an AI Admin Agent with Cortex + GitHub Copilot ( Part 1 )

Krishna Tangudu — Tue, 31 Mar 2026 15:57:14 +0000

TL;DR — Spin up a Snowflake Cortex Agent that can answer admin questions like "Which warehouses burned the most credits last month?" or "Who are my top 5 spenders?" — all from a natural-language prompt inside GitHub Copilot Chat.

The Problem

Snowflake ACCOUNT_USAGE contains everything you need to understand spend, performance, and security. The catch? You have to know the right table, the right join, and write it correctly every time.

What if you could just ask?

What You'll Build

GitHub Copilot Chat
      │  (natural language)
      ▼
MCP Server (Python, local)
      │  ask_admin tool
      ▼
Snowflake Cortex Agent
      │  routes to the right semantic view
      ▼
SNOWFLAKE.ACCOUNT_USAGE (+ optional ORGANIZATION_USAGE)

By the end you'll be able to type questions like these into Copilot Chat and get back answers with real numbers:

What are total compute credits by warehouse in the last 30 days?
Which users consumed the most credits this month?
How many failed logins occurred in the last 7 days?
What are serverless credits by service type?

Prerequisites

Requirement	Notes
Snowflake account (any paid edition)	`ACCOUNTADMIN` or a role with `ACCOUNT_USAGE` access
Python 3.9+	For the MCP bridge
VS Code + GitHub Copilot Chat	Agent mode enabled
Git	To clone the template

Step 1 — Clone the Template

git clone https://github.com/LALITHASWAROOPK/agent_snowflake_admin_assistant.git
cd agent_snowflake_admin_assistant/agent_snowflake_admin

Open the folder in VS Code:

code .

Step 2 — Deploy the SQL Objects (5 scripts, ~5 minutes)

All SQL is in the sql/ folder. Replace the four placeholders before running:

Placeholder	What to set
`<APP_DB>`	A database to hold your views/agent
`<APP_SCHEMA>`	Schema inside that database
`<ADMIN_ROLE>`	Role that owns the objects
`<DEVELOPER_ROLE>`	Role that will query the agent
`<EXEC_WAREHOUSE>`	Warehouse the agent will use at runtime

Run them in order in a Snowflake worksheet or SnowSQL:

@sql/01_create_views.sql        -- Base views over ACCOUNT_USAGE
@sql/02_create_semantic_views.sql  -- Semantic layer (natural-language metadata)
@sql/03_create_agent.sql        -- Cortex Agent wired to those views
@sql/04_create_budget.sql       -- Optional: spending guardrails
@sql/05_grants.sql              -- RBAC grants

What the Views Cover

01_create_views.sql builds seven base views, all sourced exclusively from SNOWFLAKE.ACCOUNT_USAGE — no custom tables, no proprietary schemas:

View	Source
`V_WAREHOUSE_COST_BY_TAG`	`WAREHOUSE_METERING_HISTORY` + `TAG_REFERENCES`
`V_QUERY_PERFORMANCE`	`QUERY_HISTORY`
`V_USER_SPEND`	`QUERY_ATTRIBUTION_HISTORY`
`V_SERVERLESS_COSTS`	Tasks, pipes, clustering, search, MV refresh
`V_STORAGE_USAGE`	`STORAGE_USAGE` + `DATABASE_STORAGE_USAGE_HISTORY`
`V_LOGIN_HISTORY`	`LOGIN_HISTORY`
`V_DATA_TRANSFER`	`DATA_TRANSFER_HISTORY` + `REPLICATION_USAGE_HISTORY`

02_create_semantic_views.sql wraps each base view with a COMMENT block that tells the Cortex Agent what the view is for — this is how the agent knows which view to query for any given question.

Why Semantic Views?

Snowflake Cortex Agents use semantic views as tool definitions. A semantic view is just a standard view with a COMMENT that describes its purpose in natural language. The agent reads those comments at inference time to decide which tool (view) answers the user's question.

No prompt engineering required on your end.

Step 3 — Start the MCP Bridge

The MCP (Model Context Protocol) server is a lightweight Python HTTP server that exposes one tool — ask_admin — which Copilot Chat can call.

Install dependencies

pip install -r mcp/requirements.txt

Configure your environment

Create a .env file in the repo root (never commit this):

SNOWFLAKE_ACCOUNT=<your_account>
SNOWFLAKE_USER=<your_user>
SNOWFLAKE_AUTHENTICATOR=externalbrowser
SNOWFLAKE_ROLE=<DEVELOPER_ROLE>
SNOWFLAKE_WAREHOUSE=<EXEC_WAREHOUSE>
SNOWFLAKE_AGENT_FQN=<APP_DB>.<APP_SCHEMA>.<AGENT_NAME>
MCP_PORT=3000

Supports externalbrowser (SSO), snowflake (password), and OAuth — set SNOWFLAKE_AUTHENTICATOR and the matching credential variable.

Launch the server

./scripts/start-mcp.ps1

Or directly:

python mcp/server.py

Verify it's up:

Invoke-RestMethod -Uri http://127.0.0.1:3000/health -Method Get
# → {"status":"ok"}

Step 4 — Connect Copilot Chat

The repo ships a pre-configured .vscode/mcp.json that wires the local MCP server into VS Code:

{
  "mcpServers": {
    "snowflake-admin": {
      "url": "http://127.0.0.1:3000"
    }
  }
}

VS Code picks this up automatically when you open the workspace. You'll see the ask_admin tool listed inside Copilot Chat's tool picker.

There's also a GitHub Copilot instruction file at .github/instructions/admin.instructions.md which gives Copilot context about the agent's scope so it routes questions there automatically.

Step 5 — Ask It Questions

Switch Copilot Chat to Agent mode and try:

What are my top 5 warehouses by compute credits in the last 30 days?

Which users have spent the most credits this month?

Show me failed logins by user in the last 7 days.

What serverless services are costing me the most right now?

What's my current storage usage broken down by database?

The agent selects the right semantic view, runs the query, and returns a plain-English answer with the numbers inline — no SQL, no context switching.

Optional: Budget Guardrails

04_create_budget.sql sets up a Snowflake Budget object so you can enforce credit limits at the agent level. Handy for keeping a shared admin agent from running runaway queries:

CALL <APP_DB>.<APP_SCHEMA>.<BUDGET_NAME>!SET_SPENDING_LIMIT(100);
CALL <APP_DB>.<APP_SCHEMA>.<BUDGET_NAME>!GET_SPENDING_HISTORY();

Architecture Recap

┌─────────────────────────────────────┐
│         GitHub Copilot Chat         │
│      (Agent mode + ask_admin tool)  │
└────────────────┬────────────────────┘
                 │ HTTP / MCP
┌────────────────▼────────────────────┐
│      MCP Bridge  (mcp/server.py)    │
│  Exposes: /mcp/tools/list           │
│           /mcp/tools/call           │
│           /health                   │
└────────────────┬────────────────────┘
                 │ snowflake-connector-python
┌────────────────▼────────────────────┐
│   SNOWFLAKE.CORTEX.DATA_AGENT_RUN   │
│   ← Cortex Agent (semantic router)  │
└────────────────┬────────────────────┘
                 │ picks the right tool
┌────────────────▼────────────────────┐
│     Semantic Views (SV_*)           │
│     Base Views    (V_*)             │
│     ↑ SNOWFLAKE.ACCOUNT_USAGE       │
└─────────────────────────────────────┘

Key Things to Know

Account Usage latency: SNOWFLAKE.ACCOUNT_USAGE is typically delayed by up to a few hours — not real-time.
Rate sheet: ORGANIZATION_USAGE.RATE_SHEET_DAILY is optional and depends on your edition/region.
Auth flexibility: The MCP server supports SSO (externalbrowser), OAuth, and password auth — configure once in .env.

Get the Code

github.com/LALITHASWAROOPK/agent_snowflake_admin_assistant

PRs and issues welcome. If you build on top of this, tag me — I'd love to see what you add.

How Snowflake’s RELY Constraint Supercharges Your Star‑Schema Queries

Krishna Tangudu — Thu, 19 Mar 2026 18:49:36 +0000

Snowflake’s RELY constraint is a powerful but under‑used hint that tells the optimizer it can trust your primary keys and foreign keys and use them to eliminate unnecessary work—especially redundant joins. In this post, I’ll explain what RELY does, how it helps with join elimination, and walk you through concrete examples you can adapt for your own schemas.

Why this matters to a data engineer?

If you’ve ever used wide, reusable models with hundreds of columns designed as a single source of truth, you know how easily queries can accumulate unnecessary joins. RELY helps here by letting Snowflake eliminate redundant joins when they’re logically not needed, so queries only scan the tables that actually contribute to the result.

In Snowflake, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints on standard tables are not enforced by default; they are mainly metadata for humans and tools. However, Snowflake lets you add a RELY property on those constraints to signal:

I guarantee this constraint is true in my data, and you can use it to rewrite my queries.

You set RELY like this:

ALTER TABLE dim_customer
  ALTER PRIMARY KEY RELY;

ALTER TABLE fact_sales
  ALTER CONSTRAINT fk_customer_id RELY;

When does RELY kick in?

Snowflake can use RELY‑tagged constraints to eliminate unnecessary joins when:

A table has a PRIMARY KEY or UNIQUE constraint marked RELY.
A related table has a FOREIGN KEY constraint also marked RELY.
The query joins on those keys, but doesn’t actually need any columns from one of the joined tables beyond the key itself.

In those situations, Snowflake can realize that the join is “logically redundant” and rewrite the plan to drop the table scan entirely.

This is a cost-saving measure as it rewrites the query to eliminate unnecessary tables, allowing for faster performance. Additionally, may allows us to use a smaller warehouse may help reduce overall costs.

Example 1: Simple join elimination with sample data

CREATE TABLE dim_customer (
  customer_id INT PRIMARY KEY,
  customer_name VARCHAR
);

CREATE TABLE fact_sales (
  sale_id INT,
  customer_id INT,
  amount DECIMAL(10,2),
  sale_date DATE,
  CONSTRAINT fk_customer_id FOREIGN KEY (customer_id) REFERENCES dim_customer (customer_id)
);

Sample data:

INSERT INTO dim_customer VALUES
  (1, 'Alice'),
  (2, 'Bob'),
  (3, 'Charlie');

INSERT INTO fact_sales VALUES
  (101, 1, 100.00, '2026-01-01'),
  (102, 1, 150.00, '2026-01-05'),
  (103, 2, 200.00, '2026-01-03'),
  (104, 3, 300.00, '2026-01-04');

Initial query (no RELY):

SELECT
  f.customer_id,
  SUM(f.amount) AS total_amount
FROM fact_sales f
JOIN dim_customer d ON f.customer_id = d.customer_id
GROUP BY f.customer_id;

Output:

Query Plan:

Now enable RELY:

ALTER TABLE dim_customer
  ALTER PRIMARY KEY RELY;

ALTER TABLE fact_sales
  ALTER CONSTRAINT fk_customer_id RELY;

Under the hood, Snowflake sees:

dim_customer.customer_id is unique and trusted (PRIMARY KEY RELY).
fact_sales.customer_id is a trusted foreign key (fk_customer_id RELY).
The only column used from dim_customer is customer_id, which is already in fact_sales.

So the optimizer eliminates the join to dim_customer and rewrites the query plan like below:

The result is identical, but the execution plan no longer scans dim_customer at all.

Example 2: Join elimination with filters (and when it doesn’t kick in)

SELECT
  f.customer_id,
  SUM(f.amount) AS total_amount
FROM fact_sales f
JOIN dim_customer d ON f.customer_id = d.customer_id
WHERE d.customer_name = 'Alice'
GROUP BY f.customer_id;

Here, dim_customer.customer_name is used in the filter, so the join on dim_customer is not redundant even with RELY. The optimizer must still fetch dimension data to evaluate the WHERE clause, so join elimination does not occur.

Example 3: RELY in a multi‑dimension star schema

CREATE OR REPLACE TABLE dim_customer (
  customer_id INT PRIMARY KEY,
  customer_name VARCHAR
);

CREATE OR REPLACE  TABLE dim_channel (
  channel_id INT PRIMARY KEY,
  channel_name VARCHAR
);

CREATE OR REPLACE TABLE fact_sales (
  sale_id INT,
  customer_id INT,
  channel_id INT,
  amount DECIMAL(10,2),
  sale_date DATE,

  CONSTRAINT fk_customer FOREIGN KEY (customer_id) REFERENCES dim_customer (customer_id),
    CONSTRAINT fk_channel FOREIGN KEY (channel_id) REFERENCES dim_channel (channel_id)
);

## Sample Data

-- dimensions
INSERT INTO dim_customer VALUES (1, 'Alice'), (2, 'Bob');
INSERT INTO dim_channel VALUES (1, 'Online'), (2, 'In‑store');

-- facts
INSERT INTO fact_sales VALUES
  (101, 1, 1, 100.00, '2026-01-01'),
  (102, 1, 2, 200.00, '2026-01-02'),
  (103, 2, 1, 150.00, '2026-01-03');

## Now Enable Rely

ALTER TABLE dim_customer
  ALTER PRIMARY KEY RELY;

ALTER TABLE dim_channel
  ALTER PRIMARY KEY RELY;

ALTER TABLE fact_sales
  ALTER CONSTRAINT fk_customer RELY;

ALTER TABLE fact_sales
  ALTER CONSTRAINT fk_channel RELY;

If you run a query that only aggregates by fact keys:

SELECT
  f.customer_id,
  f.channel_id,
  SUM(f.amount) AS total_amount
FROM fact_sales f
JOIN dim_customer d_c ON f.customer_id = d_c.customer_id
JOIN dim_channel d_ch ON f.channel_id = d_ch.channel_id
GROUP BY f.customer_id, f.channel_id;

Here, dim_channel and dim_customer are only used for their keys, which are already in fact_sales. With RELY, Snowflake can understand that:

dim_customer.customer_id is unique and trusted.
dim_channel.channel_id is unique and trusted.
The join columns are already present in fact_sales.

So it can eliminate both joins, effectively turning the query into:

How RELY helps performance in practice
By enabling RELY on trusted PK/FK constraints, you give the optimizer permission to:

Drop unnecessary dimensions from analytical queries that only reference key columns.
Short‑circuit joins and reduce the number of operators in the plan, which often lowers merge‑join/hash‑join overhead.
Reduce memory and compute usage, especially for large fact tables that are joined repeatedly in BI or ad‑hoc workloads.

Important caveats and best practices

Because RELY is a trust‑me hint, a few caveats matter:

You are responsible for enforcing UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints. If those constraints are violated, query results with RELY can differ from those with NORELY.
Always validate data via ETL (e.g., dbt tests) before setting RELY, as violations can lead to suboptimal plans
Timestamp_tz PKs or hybrid tables limit elimination

Part 2: Zero-Copy data federation Snowflake Customer 360 Data to Salesforce Sales Reps

Krishna Tangudu — Wed, 18 Mar 2026 18:00:00 +0000

In Part 1, we connected Salesforce Data Cloud to Snowflake for analytics. In this blog, you'll flip the direction: surface your Snowflake Customer 360 model (Orders, Service contracts, invoices, Repairs, etc.) directly into Salesforce so your sales and service teams can activate it in real time—without ETL or data duplication.

Snowflake ↔ Salesforce Data Cloud ↔ Salesforce CRM

Snowflake: Owns Customer 360 models, health scores, churn risk

Zero-Copy: Data Cloud queries Snowflake live (pushdown SQL)

Salesforce: Activates signals (flows, UI, campaigns)

Architecture Pattern

Your data team builds 'CUSTOMER_360_VIEW' with 'ACCOUNT_ID', 'HEALTH_SCORE', 'CHURN_RISK', 'NEXT_BEST_PRODUCT'
Modeled once, governed in Snowflake (roles, masking, row access)
Updated via your ELT pipelines (daily/hourly)

Step 1: Building data model in Snowflake


-- ============================================================
-- COMPLETE DEMO SCRIPT: Accounts + Customer 360 + Final Table
-- ============================================================

-- Optional: set your context
-- USE ROLE <your_role>;
-- USE WAREHOUSE <your_warehouse>;
-- USE DATABASE <your_database>;
-- USE SCHEMA <your_schema>;

-- ------------------------------------------------------------
-- 1) Clean up old objects (safe for reruns)
-- ------------------------------------------------------------
DROP TABLE IF EXISTS ACCOUNT_C360_SNAPSHOT;
DROP TABLE IF EXISTS CUSTOMER_360_METRICS;
DROP TABLE IF EXISTS ACCOUNTS;

-- ------------------------------------------------------------
-- 2) Create source tables
-- ------------------------------------------------------------
CREATE OR REPLACE TABLE ACCOUNTS (
    ACCOUNT_ID NUMBER,
    ACCOUNT_NAME STRING,
    INDUSTRY STRING,
    ANNUAL_REVENUE NUMBER(18,2),
    DELETED_AT TIMESTAMP_NTZ
);

CREATE OR REPLACE TABLE CUSTOMER_360_METRICS (
    ACCOUNT_ID NUMBER,
    HEALTH_SCORE FLOAT,
    CHURN_RISK FLOAT,
    NPS_SCORE NUMBER(5,2),
    ARR NUMBER(18,2),
    NEXT_BEST_PRODUCT STRING,
    LAST_ENGAGEMENT_DATE DATE
);

-- ------------------------------------------------------------
-- 3) Insert sample data (toy companies)
-- ------------------------------------------------------------
INSERT INTO ACCOUNTS (ACCOUNT_ID, ACCOUNT_NAME, INDUSTRY, ANNUAL_REVENUE, DELETED_AT) VALUES
(1001, 'Bright Blocks Toys',  'Toys', 25000000, NULL),
(1002, 'Rocket Wheels Co',    'Toys',  8000000, NULL),
(1003, 'Cuddle Critters Inc', 'Toys', 12000000, NULL),
(1004, 'Puzzle Planet Ltd',   'Toys', 30000000, NULL),
(1005, 'Old Toy Factory',     'Toys',  5000000, '2025-01-15 10:00:00'),
(NULL, 'Bad Row',             'Toys',   100000, NULL);

INSERT INTO CUSTOMER_360_METRICS (
    ACCOUNT_ID, HEALTH_SCORE, CHURN_RISK, NPS_SCORE, ARR, NEXT_BEST_PRODUCT, LAST_ENGAGEMENT_DATE
) VALUES
(1001, 0.91, 0.22, 60, 1800000, 'STEM Robot Kit',           '2026-03-10'),
(1002, 0.67, 0.45, 35,  650000, 'Turbo Track Racing Set',   '2026-03-05'),
(1003, 0.43, 0.81, 10,  420000, 'Deluxe Plush Care Pack',   '2026-02-20'),
(1004, 0.80, 0.70, 55, 2200000, 'Master Puzzle Collection', '2026-03-14'),
(9999, 0.95, 0.10, 70,  900000, 'Collector Train Set',      '2026-03-01'); -- no matching account

-- ------------------------------------------------------------
-- 4) Create final table using your view definition logic
-- ------------------------------------------------------------
CREATE OR REPLACE TABLE ACCOUNT_C360_SNAPSHOT AS
SELECT
    A.ACCOUNT_ID,
    UPPER(A.ACCOUNT_NAME) AS ACCOUNT_NAME,
    A.INDUSTRY,
    A.ANNUAL_REVENUE,
    C360.HEALTH_SCORE,
    C360.CHURN_RISK,
    C360.NPS_SCORE,
    C360.ARR,
    C360.NEXT_BEST_PRODUCT,
    C360.LAST_ENGAGEMENT_DATE,
    CASE
        WHEN C360.HEALTH_SCORE >= 0.8 THEN 'Healthy'
        WHEN C360.HEALTH_SCORE >= 0.5 THEN 'At Risk'
        ELSE 'Critical'
    END AS HEALTH_STATUS,
    CASE
        WHEN C360.CHURN_RISK >= 0.7 THEN 'High'
        WHEN C360.CHURN_RISK >= 0.4 THEN 'Medium'
        ELSE 'Low'
    END AS CHURN_RISK_LEVEL,
    CURRENT_TIMESTAMP() AS LAST_UPDATED
FROM ACCOUNTS A
INNER JOIN CUSTOMER_360_METRICS C360
    ON A.ACCOUNT_ID = C360.ACCOUNT_ID
WHERE A.ACCOUNT_ID IS NOT NULL
  AND A.DELETED_AT IS NULL;

Data Cloud keeps a **virtual reference to Snowflake views—no data duplication, always fresh**

Step 2: Connecting Salesforce Data Cloud to Snowflake using zero copy data federation

First, review your network policies and ensure that Salesforce Data Cloud IPs are included.

Salesforce Data Cloud connection:

Note: Make sure the private key is unencrypted and eliminate comments, such as "BEGINNING OF PRIVATE KEY" and "END OF PRIVATE KEY".

Create a Snowflake Data Stream in Data Cloud:

Select the required object from Snowflake:

Configure with below details:

Field	Value	Notes
Object Name	Customer_360	Simple, no special chars; this is the internal name Data Cloud uses
Category	Accounts	Helps organize data streams by business domain
Primary Key	ACCOUNT_ID	The unique identifier that joins to Salesforce Account records
Organization Unit Identifier	ACCOUNT_ID	(Optional; keep same as Primary Key unless you have a multi-tenant model)

Choose Live/Schedule:

Enable Select Acceleration only when necessary.
This approach allows Salesforce to cache data on a scheduled basis instead of querying Snowflake for every request.
When users attempt to load large volumes of data but only select a small subset of columns, querying Snowflake directly can become unnecessarily expensive. Leveraging Select Acceleration in these scenarios helps reduce compute costs and improves query performance by avoiding repeated full-table scans.

Step 3. Salesforce as Activation Layer

Sales reps see Snowflake signals in Account/Opportunity pages, flows create tasks automatically

Maps ACCOUNT_ID → Data Cloud profile, pulls HEALTH_SCORE, CHURN_RISK

Live signals drive real-time actions without swivel-chair between BI and CRM.

Monitoring:

Queries fired by Salesforce can be monitored in snowflake in Query History:

Governance & Ownership

Snowflake: Data ownership, model logic, calculations
Data Cloud: Unification, activation logic
Salesforce: UX, workflows, business rules

Key patterns from production:

Snowflake auto-scaling handles Data Cloud query bursts
Explicit 'GRANT SELECT' on views (not tables) for least privilege
Data Cloud refresh schedule matches Snowflake pipeline cadence

Production Impact

Before: Sellers export CSV from Snowflake → manual Salesforce upload
After: Zero-copy signals → automatic tasks → faster CSM response

What's next?

Salesforce Data Cloud also provides an option for file‑based federation when using the Snowflake Polaris Catalog Account.

This enables data access without continuously querying Snowflake, offering an alternative integration pattern for specific use cases.

Whether this capability will be extended to the Horizon Catalog remains to be seen—something to watch as the platform evolves.

Part 1: Zero-Copy Sharing – Salesforce Snowflake for Analytics

Krishna Tangudu — Thu, 12 Mar 2026 16:00:00 +0000

The ETL Nightmare Ends

Salesforce holds your richest customer data—opportunities, accounts, contacts—but getting it into Snowflake for analytics usually means painful ETL pipelines, schema drift, and maintenance hell. Zero-copy data Federation sharing changes everything: Salesforce publishes secure shares that land in Snowflake as native objects, queryable instantly without duplication or latency.

We are currently in the process of implementing Salesforce Sales Cloud. In this first part of a 2-part series, I'll walk through the exact OAuth setup, common integration traps (network policies! URL underscores!), and best practices for analytics teams.

Architecture Overview

Zero-copy sharing flips traditional pipelines: Salesforce Data Cloud becomes the secure publisher, Snowflake the consumer.

Layer	Owner	Contains
Source	Salesforce Sales Cloud	Raw CRM objects (OPPORTUNITY, ACCOUNT, CONTACT)
Share	Salesforce Data Cloud	Secure data share with selected objects
Consumer DB	Snowflake	Read-only shared objects like SFDC.OPPORTUNITY
Analytics Layer	Snowflake	Views, models, dashboards built on shared data

Salesforce Datacloud handles object sharing; Snowflake analysts query familiar objects immediately. No Fivetran, no Airflow, no storage costs for duplicates.

Step-by-Step Setup

Before you begin:

Make sure that your Snowflake admin adds the Data 360 IP Addresses to the allowlist.

Supported Regions for Snowflake Integration

In Snowflake
Step 1: Snowflake Security Integration

CREATE OR REPLACE SECURITY INTEGRATION sf_integration
  TYPE = OAUTH
  OAUTH_CLIENT = CUSTOM
  OAUTH_CLIENT_TYPE = 'CONFIDENTIAL'
  OAUTH_REDIRECT_URI = 'https://test.salesforce.com/services/cdp/SnowflakeOAuthCallback'
  ENABLED = TRUE
  OAUTH_ISSUE_REFRESH_TOKENS = TRUE;

Prod tip: Swap test.salesforce.com for login.salesforce.com in production.

Step 2: Snowflake Integration User (Not required if the user creating a data target on Salesforce already has a login using Azure or a native user in Snowflake.)

CREATE OR REPLACE USER sf_integration_user
  LOGIN_NAME = 'sf_integration_user'
  PASSWORD = '<secure-password>'
  DEFAULT_ROLE = 'sf_integration_role'
  EMAIL = 'your-email@company.com';
Grant minimal privileges: USAGE on warehouse, SELECT on consumer database.

Step 3: Client Secrets & Salesforce Config

SELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS('sf_integration');

Copy both client ID and secret to Salesforce Data Cloud.

Step 4: Salesforce Data Target
Salesforce team configures:

Account URL: https://my-account-us-east-1.snowflakecomputing.com
Critical: if your Snowflake URL has underscores (my_account_us-east-1), convert to hyphens (my-account-us-east-1) in the Account URL field.

Authentication: OAuth (using secrets from step 3)

Step 5: Publish to Share:
The Salesforce team should create a data stream and a data lake object, then add this object to the created Data Share Target.

Data Stream ( Address ):

Data Lake Object:

Salesforce publishes share → Snowflake receives:

CREATE DATABASE sf_shared FROM SHARE <ShareName>;

Integration Issues & Fixes
80% of failures happen here. Lessons from this activity:

Network Policies Block Everything
Snowflake network policies can silently prevent Salesforce Data cloud IP ranges.
Check: SHOW NETWORK POLICIES;
Fix: Add Salesforce Data cloud IPs

Account URL Underscores → Hyphens
Salesforce rejects Snowflake URLs with _. Always transform:

Check Permissions
Check the permissions of the user who is trying to establish the connection

Note: This setup is only required one time.

Best Practices for Analytics Teams

Layered Architecture

SF_SHARED (raw, read-only)
↓
SF_ANALYTICS (views, materialized)
↓
BI tools (Power BI, Tableau)

Governance

Enable only semantic view access : grant USAGE on raw share to business users
Create weekly Alert to monitor Schema drift breaks downstream views Salesforce owns object changes (new fields, deletions)
Materialize frequent aggregates like below

CREATE MATERIALIZED VIEW analytics.opp_pipeline_summary AS
SELECT stage, COUNT(*) as count, AVG(amount) as avg_amount
FROM sf_shared.sfdc.opportunity
GROUP BY stage;
Cost Control

Use multi-cluster warehouses for concurrent BI queries
Monitor: QUERY_HISTORY() for expensive shared table scans

Take Away:
0 TB duplicated storage, 30% faster pipeline deployment, 100% schema fidelity.

Quick Wins Checklist

[ ] URL underscores → hyphens
[ ] Network policy allows Salesforce IPs
[ ] Test OAuth token refresh before prod
[ ] Raw share → semantic views (don't expose raw)

What's Next (Part 2 Teaser)
This gets Salesforce data into Snowflake seamlessly. In Part 2, we reverse direction: Snowflake Customer 360 data flowing back to sales reps in Salesforce via data federation

Quick Start Your Integration

✅ Fork: https://github.com/LALITHASWAROOPK/salesforce-snowflake-zero-copy

Part 2 → Customer 360 (Snowflake → Salesforce)

Krishna Tangudu

Mar 18

Part 2: Zero-Copy data federation Snowflake Customer 360 Data to Salesforce Sales Reps

#cloud #dataengineering #salesforce #snowflake

Comments

4 min read

Try this yourself: Share your biggest Salesforce-Snowflake integration pain point in the comments!

Setting up Snowflake–Power BI Connectivity with Azure AD SSO and Auto-Provisioning

Krishna Tangudu — Thu, 12 Mar 2026 14:18:02 +0000

Overview:

This post walks through how to enable end-to-end SSO from Power BI to Snowflake using Azure AD, while automatically provisioning users and roles via SCIM. It’s designed for enterprise BI scenarios where analysts connect with DirectQuery or scheduled refresh and you want their Azure AD identity and group membership to control Snowflake access without manual user administration.

Step 1. Configure SSO to Snowflake with Azure AD

Step 1.1: Register Snowflake in Azure AD
Ask your Azure team to register the Snowflake application in Azure AD using these values (replace with your account locator):

Identifier (Entity ID):
https://<account_locator>.snowflakecomputing.com/

Reply URL:
https://<account_locator>.snowflakecomputing.com/fed/login

Sign On URL:
https://<account_locator>.snowflakecomputing.com/

Sign Out URL:
https://<account_locator>.snowflakecomputing.com/fed/logout

Step 1.2: Collect SAML metadata from Azure AD

EntityID in the form: https://sts.windows.net// → use as SAML2_ISSUER

Location in the form: https://login.microsoftonline.com//saml2 → use as SAML2_SSO_URL

X509Certificate → use as SAML2_X509_CERT

SAML2_PROVIDER → set to CUSTOM when Azure AD is the IdP

Step 1.3: Create the SAML2 integration in Snowflake

Run as ACCOUNTADMIN:

USE ROLE ACCOUNTADMIN;

CREATE SECURITY INTEGRATION <AZURE_AD_SSO_NAME>
  TYPE = SAML2
  ENABLED = TRUE
  SAML2_ISSUER = '<EntityID from metadata>'
  SAML2_SSO_URL = '<Location from metadata>'
  SAML2_PROVIDER = 'CUSTOM'
  SAML2_X509_CERT = '<X509 certificate>'
  SAML2_SP_INITIATED_LOGIN_PAGE_LABEL = 'AzureADSSO'
  SAML2_ENABLE_SP_INITIATED = TRUE;

This enables browser SSO into Snowflake via Azure AD

Step 2: Enable Automatic Provisioning with SCIM

2.1 Create functional Azure groups
Have the support/AD team create AD groups following a functional-role naming convention, for example:

DEVELOPER-SNOWFLAKE
ADMIN-SNOWFLAKE
SUPPORT-SNOWFLAKE

These group names will become Snowflake role names via SCIM and act as default roles.

Step 2.2: Create SCIM integration in Snowflake

Run as ACCOUNTADMIN:

CREATE ROLE IF NOT EXISTS AAD_PROVISIONER;

GRANT CREATE USER ON ACCOUNT TO ROLE AAD_PROVISIONER;
GRANT CREATE ROLE ON ACCOUNT TO ROLE AAD_PROVISIONER;

GRANT ROLE AAD_PROVISIONER TO ROLE ACCOUNTADMIN;
GRANT ROLE AAD_PROVISIONER TO ROLE SYSADMIN;

CREATE OR REPLACE SECURITY INTEGRATION AAD_PROVISIONING
  TYPE = SCIM
  SCIM_CLIENT = 'azure'
  RUN_AS_ROLE = 'AAD_PROVISIONER';

Then generate the SCIM access token:

SELECT SYSTEM$GENERATE_SCIM_ACCESS_TOKEN('AAD_PROVISIONING');

Notes:

Token validity is 6 months; you must regenerate it periodically.
Add monitoring/alerting to renew before expiry

Step 2.3 Share SCIM details with Azure team

Tenant URL:
https://.snowflakecomputing.com/scim/v2/

Secret Token: The SCIM access token generated above

They will configure the Snowflake enterprise app in Microsoft Entra ID (Azure AD) for automatic provisioning, following Microsoft’s “Configure Snowflake for automatic user provisioning with Microsoft Entra ID” tutorial.

Step 3. Configure SSO from Power BI to Snowflake

Step 3.1: Security Integration creation

CREATE OR REPLACE SECURITY INTEGRATION CM_SC_<ACCOUNT_LOCATOR>_SSO_POWERBI_SNFK
  TYPE = EXTERNAL_OAUTH
  ENABLED = TRUE
  EXTERNAL_OAUTH_TYPE = AZURE
  EXTERNAL_OAUTH_ISSUER = '<EntityID from Step 2 (https://sts.windows.net/.../)>'
  EXTERNAL_OAUTH_JWS_KEYS_URL = 'https://login.windows.net/common/discovery/keys'
  EXTERNAL_OAUTH_AUDIENCE_LIST = (
    'https://analysis.windows.net/powerbi/connector/Snowflake',
    'https://analysis.windows.net/powerbi/connector/snowflake'
  )
  EXTERNAL_OAUTH_TOKEN_USER_MAPPING_CLAIM = 'upn'
  EXTERNAL_OAUTH_SNOWFLAKE_USER_MAPPING_ATTRIBUTE = 'login_name';
--UPN in Azure AD matches the login_name or email

ALTER SECURITY INTEGRATION CM_SC_<ACCOUNT_LOCATOR>_SSO_POWERBI_SNFK
  SET EXTERNAL_OAUTH_ANY_ROLE_MODE = 'ENABLE'; -- This allows additional roles

Step 3.2 Grant Snowflake access for Power BI users
Grant appropriate warehouse and database access to the Snowflake roles that are created.

GRANT USAGE ON WAREHOUSE <WAREHOUSENAME>
  TO ROLE "DEVELOPER-SNOWFLAKE";

GRANT USAGE ON DATABASE <DATABASENAME>
  TO ROLE "DEVELOPER-SNOWFLAKE";

GRANT USAGE ON SCHEMA <DATABASENAME.SCHEMANAME>
  TO ROLE "DEVELOPER-SNOWFLAKE";

GRANT SELECT ON ALL TABLES IN SCHEMA <DATABASENAME.SCHEMANAME>
  TO ROLE "DEVELOPER-SNOWFLAKE";

Step 3.3 Network policy and IP ranges

If you use Snowflake network policies, ensure the policy allows:

Power BI service IP ranges
Azure AD IP ranges
Microsoft publishes updated IP ranges here:
https://www.microsoft.com/en-us/download/details.aspx?id=56519

Step 4: Using it from Power BI

Once everything above is configured:

In Power BI (Desktop or Service), use the Snowflake connector.
Sign in with your Azure AD (organizational) account.
The connector obtains an Azure AD token, which Snowflake validates via the EXTERNAL_OAUTH integration, mapping the upn claim to the Snowflake login_name.

Note:
If connecting using PowerBI Service, please use Server Name as all lower case, otherwise MS PBI interface gives weird errors.

Understanding Snowflake Virtual Warehouses

Krishna Tangudu — Mon, 09 Mar 2026 09:28:08 +0000

I did something that could have disrupted our production queries: I suspended all our Snowflake warehouses during a maintenance window. This action might have caused loading errors in our dashboards. Surprisingly, everything loaded perfectly, with results returning in mere milliseconds. This experience was not a fluke; it marked my first real "aha moment" about how fundamentally different Snowflake's architecture is from that of traditional data warehouses.

After three years as a Snowflake architect, I've realized that truly understanding virtual warehouses isn't just about knowing T-shirt sizes or auto-suspend settings. It's about understanding an architecture that challenges everything we learned from legacy systems.

This is Part 1 of a series where I'll share what I've learned in the trenches. Let's start with the fundamentals. ## The Discovery: Queries Without Compute? Here's what happened: Our BI team ran their morning reports. Warehouses were suspended. Queries succeeded. No compute credits consumed. How?

**Three layers of caching saved us:

1.Result Cache (24 hours) - If someone ran the exact same query in the last 24 hours with no data and parameters (e.g., timezone ) changed then Snowflake returns the cached result. No warehouse needed. No cost.

USE WAREHOUSE COMPUTE_WH;
USE DATABASE SNOWFLAKE_SAMPLE_DATA;
USE SCHEMA TPCH_SF10; 
SELECT distinct l_partkey FROM LINEITEM;

When you run it for the first time, it will scan the required data as shown below:

When you execute the query again, it will utilize the result cache, as demonstrated below:

2.Metadata Cache - Simple aggregations like COUNT(*) or MIN/MAX on clustered columns? Often answered from metadata alone.

SELECT COUNT(*) AS lineitem_rows FROM LINEITEM;

3.Local Disk Cache - When a warehouse does spin up, frequently accessed data sits in SSD cache for ultra-fast retrieval

If I add another column to the existing query, it will attempt to use the local warehouse cache.

SELECT distinct **l_orderkey, ** l_partkey FROM LINEITEM;

This taught me something critical:
In Snowflake, your warehouse isn't your database. It's just a compute engine you rent when you need it.

Please refer to this article, which provides a great starting point for understanding caching in Snowflake.

Snowflake Community

community.snowflake.com

What Actually Is a Virtual Warehouse?

Think of virtual warehouses as ephemeral compute clusters that live completely separately from your data. Traditional warehouse: Compute + Storage = One monolithic system Snowflake warehouse: Compute ← (network) → Storage (separate, scalable independently) This separation is Snowflake's superpower. Your data lives in cloud storage (S3, Azure Blob, GCS). Warehouses are just compute resources that: - Spin up in seconds - Process queries - Shut down automatically - Scale independently of storage You can have 10 warehouses querying the same table simultaneously. Or zero warehouses with your data perfectly safe.

The T-Shirt Sizing Reality Snowflake offers warehouse sizes from X-Small to 6X-Large.

After architecting systems at Agilent, here's what I've learned:
X-Small (1 credit/hour): - Perfect for: Dev/test, lightweight ETL, ad-hoc queries - What surprised me: Handles 80% of analytics workloads just fine - Common mistake: Over-provisioning because "bigger is safer"

Medium to Large (4-8 credits/hour): - The sweet spot for most adhoc complex production workloads - We scale up based on actual performance, not assumptions - One architect rule: If you need Larger size, first ask if you can optimize the query - Real example: We reduced a Medium job to X-Small by fixing a Cartesian join and using clustering

The counterintuitive truth: A bigger warehouse doesn't always mean faster queries. Sometimes it's a sign of inefficient SQL.

Auto-Suspend: The Feature That Saves Careers (and Budgets) Set `AUTO_SUSPEND = 60` (seconds) on every warehouse.

No exceptions. In my first month, I found warehouses left running overnight resulting in wasted spend. The dev team didn't realize that unlike traditional databases, Snowflake warehouses don't shut down automatically when queries finish.

My standard configuration:

AUTO_SUSPEND = 60 -- Suspend after 1 minute of inactivity AUTO_RESUME = TRUE -- Restart automatically when needed

One minute feels aggressive, but remember: warehouses restart in seconds, and the result cache covers most repeat queries anyway.

Real impact: This simple change cut our development environment costs by 20%.

Note

For DevOps, DataOps, and Data Science use cases, Snowflake recommends setting auto-suspension to approximately 5 minutes because the cache is not as important for ad-hoc and unique queries.
For query warehouses, for example BI and SELECT use cases, Snowflake recommends setting auto-suspend to at least 10 minutes to maintain the cache for users.

docs.snowflake.com

Auto-Resume: Trust It When `AUTO_RESUME = TRUE`,

suspended warehouses wake up automatically when queries arrive. Resume time? Usually 3-5 seconds based on size. Early in my Snowflake journey, I was nervous about this. What if a critical dashboard times out during resume? Three years later: I've never seen this cause a production issue. The resume is fast, and users don't notice. Your anxiety about suspended warehouses is costing you money.

The Misconceptions I Had (And Still Hear)

Misconception #1: "Keep warehouses running for better performance" Reality: Cold start is 3-5 seconds. Keeping a Medium warehouse running 24/7 wastes ~$2,000/month on Enterprise edition.

Misconception #2: "Bigger warehouses = faster queries"
Reality: Badly written queries stay slow regardless of size. Fix the SQL first.

Misconception #3: "We need one big warehouse for everything" Reality: Multiple specialized warehouses provide better isolation and cost control.

Misconception #4: "Warehouse size determines storage capacity" Reality: Storage is completely independent. An X-Small can query petabytes.

The Architect's Perspective: How This Changes Design Understanding warehouses changed how I design data systems:

1. Workload Isolation Instead of one shared warehouse, we run: - ETL_WH (X-Small, auto-suspend 60s) - ANALYTICS_WH (Small, auto-suspend 60s) - REPORTING_WH (Small, multi-cluster for BI tools) - DEV_WH (X-Small, auto-suspend 30s)

Why? A poorly optimized dev query can't impact production reports. Each team pays for what they use.

2. Cost Attribution Tagged warehouses let us track costs by department, project, or team. Finance loves this.

3. Right-Sizing Strategy Start small. Scale up only when performance metrics justify it. We monitor query execution time and queuing, not gut feelings.

4. Embrace Suspension Our warehouses spend 90% of their time suspended. That's not a problem—it's efficient architecture. ## What's Coming in This Series Over the next few weeks, I'll dive deeper: Part 2: Warehouse Optimization & Cost Control (multi-cluster warehouses, scaling policies, cost monitors) Part 3: Advanced Patterns (workload management, query acceleration, clustering, search optimization) Part 4: Monitoring & Troubleshooting (the queries I run daily, how to spot inefficiencies) Part 5: Iceberg Lakehouse Architecture

The Bottom Line

After three years architecting on Snowflake, here's what I tell every new team: Virtual warehouses aren't databases. They're temporary compute resources you rent by the second. The moment you internalize this, everything else clicks into place.

That suspended warehouse isn't "off"—your data is still there, your caches are warm, and your next query is just 3 seconds away from full compute power. Stop treating Snowflake like it's Oracle or HANA. Start treating warehouses like the elastic, ephemeral resources they are.

What's been your biggest "aha moment" with Snowflake?
Comment your cache gotcha! —I learn as much from your experiences as you might from mine.

Let me know when you drop a warehouse from Snowflake. Will the result cache still work?

Found this helpful? Follow me for Part 2 on warehouse optimization and cost control strategies.

DEV Community: Krishna Tangudu

Ask Your Snowflake Account Anything — Build an AI Admin Agent with Cortex + GitHub Copilot ( Part 1 )

The Problem

What You'll Build

Prerequisites

Step 1 — Clone the Template

Step 2 — Deploy the SQL Objects (5 scripts, ~5 minutes)

What the Views Cover

Why Semantic Views?

Step 3 — Start the MCP Bridge

Install dependencies

Configure your environment

Launch the server

Step 4 — Connect Copilot Chat

Step 5 — Ask It Questions

Optional: Budget Guardrails

Architecture Recap

Key Things to Know

Get the Code

How Snowflake’s RELY Constraint Supercharges Your Star‑Schema Queries

Why this matters to a data engineer?

When does RELY kick in?

Part 2: Zero-Copy data federation Snowflake Customer 360 Data to Salesforce Sales Reps

Snowflake ↔ Salesforce Data Cloud ↔ Salesforce CRM

Architecture Pattern

Step 1: Building data model in Snowflake

Step 2: Connecting Salesforce Data Cloud to Snowflake using zero copy data federation

Step 3. Salesforce as Activation Layer

Monitoring:

Governance & Ownership

Production Impact

What's next?

Part 1: Zero-Copy Sharing – Salesforce Snowflake for Analytics

The ETL Nightmare Ends

Architecture Overview

Step-by-Step Setup

Best Practices for Analytics Teams

Quick Start Your Integration

Part 2: Zero-Copy data federation Snowflake Customer 360 Data to Salesforce Sales Reps

Setting up Snowflake–Power BI Connectivity with Azure AD SSO and Auto-Provisioning

Overview:

Step 1. Configure SSO to Snowflake with Azure AD

Step 2: Enable Automatic Provisioning with SCIM

Step 3. Configure SSO from Power BI to Snowflake

Step 4: Using it from Power BI

Understanding Snowflake Virtual Warehouses

Snowflake Community

What Actually Is a Virtual Warehouse?

The T-Shirt Sizing Reality Snowflake offers warehouse sizes from X-Small to 6X-Large.

Auto-Suspend: The Feature That Saves Careers (and Budgets) Set AUTO_SUSPEND = 60 (seconds) on every warehouse.

Auto-Resume: Trust It When AUTO_RESUME = TRUE,

The Misconceptions I Had (And Still Hear)

The Architect's Perspective: How This Changes Design Understanding warehouses changed how I design data systems:

The Bottom Line

Auto-Suspend: The Feature That Saves Careers (and Budgets) Set `AUTO_SUSPEND = 60` (seconds) on every warehouse.

Auto-Resume: Trust It When `AUTO_RESUME = TRUE`,