Connecting Power BI to Snowflake - SSO Setup and Practical Tips

Snowflake has been showing up in more and more of our Australian client environments over the past couple of years. It used to be that everyone was on Azure SQL or Synapse, but Snowflake's consumption-based pricing and separation of compute from storage has pulled in a lot of organisations - particularly in financial services and retail.

The question that follows is always the same: how do we get Power BI connected to it properly?

The short answer is that the connector works well, but the SSO configuration with Microsoft Entra ID has enough steps across enough admin portals that it catches people out. Let me walk through what's actually involved and where things tend to go sideways.

Basic Connection vs SSO

You have two paths for connecting Power BI to Snowflake.

Basic authentication works like any other connector. You enter a username and password for a Snowflake service account, and Power BI uses those credentials to query data. This is simple to set up and works fine for development or small teams.

Microsoft Entra ID with SSO is what you want for production. With SSO enabled, each user's own Microsoft Entra credentials are passed through to Snowflake via DirectQuery. This means Snowflake's row-level security and access policies apply per user, audit logs show who actually queried what, and nobody needs to manage shared service account passwords.

The Microsoft documentation on connecting to Snowflake covers the official process, but let me fill in the gaps with what we've actually experienced.

Setting Up SSO - The Three-Admin Problem

The biggest friction point with Snowflake SSO in Power BI isn't technical complexity. It's organisational complexity. You need three different admins to each do their part, and they often don't know what the other two are doing.

Step 1 - Snowflake Admin Configuration

Your Snowflake administrator needs to configure OAuth for Power BI. Snowflake has a dedicated guide for Power BI SSO that walks through creating the OAuth integration.

This is where the external identity provider configuration happens. The Snowflake admin registers Power BI as an OAuth client and configures the token exchange. If your Snowflake admin hasn't done this before, it's not complicated - but it does require the ACCOUNTADMIN role, which means it can't be done by a regular Snowflake user.

One thing we've seen trip people up: the Snowflake account URL format matters. Make sure you're using the correct account identifier format that matches how your organisation's Snowflake instance is set up. Getting this wrong produces unhelpful authentication errors.

Step 2 - Power BI Admin Portal

A Fabric administrator (the Power BI admin role has been folded into this) needs to enable Snowflake SSO in the Power BI Admin portal.

Sign in to Power BI, go to Settings, then Admin portal, then Tenant settings. Scroll down to Integration settings and find the Snowflake SSO toggle. Enable it and click Apply.

This step gives Power BI permission to send Microsoft Entra tokens to Snowflake's servers. It's a consent step, essentially. After you enable it, wait up to an hour for the setting to propagate. I know - an hour feels excessive. But Microsoft's documentation says it, and we've seen cases where it genuinely took that long.

A small but important detail: this is a tenant-wide setting. You can scope it to specific security groups if you don't want every user in your organisation to have SSO to Snowflake through Power BI. In practice, scoping it to the users who actually have Snowflake accounts makes sense.

Step 3 - Semantic Model Configuration

After the report built on the Snowflake connector is published to the Power BI Service, the semantic model owner needs to update the data source credentials.

Go to the workspace, find the semantic model, open Settings, and look for Data source credentials. Sign in using OAuth2 (Microsoft Entra ID) credentials. Then enable the option that says "End users use their own OAuth2 credentials when accessing this data source via DirectQuery."

That last checkbox is what actually turns on the per-user SSO flow. Without it, the report uses whatever credentials were configured at publish time, which defeats the purpose.

Why SSO Actually Matters

Some teams look at all three steps above and ask whether it's worth the effort. Can't we just use a service account?

For development and internal prototyping, sure. A service account is fine. But for production reports, especially in regulated industries, SSO gives you things you can't easily replicate otherwise.

Per-user audit trails in Snowflake. When a report viewer opens a dashboard, the queries that hit Snowflake are logged against their identity, not a generic service account. For financial services clients dealing with APRA requirements, or healthcare organisations thinking about data governance, this matters.

Snowflake row-level security works naturally. If you've set up policies in Snowflake that restrict data access by user, those policies apply automatically when users view Power BI reports. Without SSO, you'd need to implement row-level security twice - once in Snowflake and once in Power BI.

No shared credential management. Service account passwords need to be rotated, stored securely, and shared between admins. With SSO, each user authenticates with their existing corporate credentials. One less password to manage.

The DirectQuery Consideration

Snowflake with SSO requires DirectQuery mode. This is non-negotiable - Import mode can't pass per-user credentials because the data is pulled at refresh time by a single account.

DirectQuery means every interaction with the report generates a live query to Snowflake. This has implications.

Performance depends on Snowflake warehouse sizing. A small XS warehouse handles exploration queries fine, but if you have fifty people opening dashboards at 9am Monday morning, you need enough compute to handle concurrent queries. Snowflake's auto-scaling helps here, but it also means costs can spike during peak usage.

Not all DAX works in DirectQuery mode. Most common calculations translate fine, but complex DAX that requires local computation may not. Test your reports thoroughly after switching to DirectQuery if you're converting from Import mode.

Report design matters more. With Import mode, a poorly designed report page with twenty visuals just loads slowly. With DirectQuery, it sends twenty separate queries to Snowflake. Design your reports to be focused, and use bookmarks or pages to break up complex dashboards rather than cramming everything onto one page.

We've written more about DirectQuery optimisation in other posts, but the short version is: fewer visuals per page, smart use of aggregation tables, and thoughtful filter design.

Troubleshooting Common Issues

Here's what we've seen go wrong and how to fix it.

"Authentication failed" after enabling SSO. Usually means the Snowflake admin hasn't completed the OAuth integration, or it was configured with the wrong account URL. Verify the Snowflake side first - Power BI's error messages don't tell you which side failed.

SSO works for the publisher but not for viewers. Check that the Tenant setting is enabled for the right security groups. Also verify that each viewer has an account in Snowflake that matches their Microsoft Entra email. The identity mapping has to line up.

Reports load slowly after switching to SSO/DirectQuery. This is usually a Snowflake warehouse sizing issue, not a Power BI issue. Check Snowflake's query history to see how long queries are actually taking. If they're running for multiple seconds each, you may need to bump the warehouse size or add aggregation tables.

Token expiry errors. Microsoft Entra tokens have a limited lifetime. If a user has a report open for hours without interacting, the token can expire. Refreshing the browser page usually resolves this. It's annoying but normal.

When Not to Use SSO

SSO with Snowflake makes sense for production reports viewed by multiple people where data governance matters. But there are situations where basic authentication is actually the better choice.

If you're building embedded analytics or paginated reports, SSO doesn't apply in the same way. If your Snowflake data is pre-aggregated and there's nothing sensitive at the row level, the overhead of SSO may not be justified. And if you're in an early-stage project where you just need to validate whether Snowflake data works for your reporting needs, basic auth is faster to set up.

Bringing It Together

The Snowflake-Power BI integration is solid once configured. The setup involves coordinating across Snowflake admin, Power BI admin, and semantic model owner - which is more of a people problem than a technical one. Get those three aligned early, run through the configuration in a non-production environment first, and the production setup will be straightforward.

If your organisation is running Snowflake and looking to build Power BI reporting on top of it, our Power BI consultants can help with the setup and optimisation. And if you're evaluating whether Snowflake is the right data platform for your analytics needs, that's a broader conversation about data strategy and business intelligence that we're happy to have.

The Microsoft-Snowflake integration keeps getting better with each release. A year ago, some of these SSO features were rough. Today they're reliable enough for production workloads. That's progress worth noting, even if the three-admin setup dance is still a bit clunky.