Forum Discussion
Continued ContributorSemantic model refresh failed - Snowflake Key Pair cloud connection
Hi julsr​,
Based on that specific error, I would investigate the semantic model-to-cloud-connection binding before changing the Snowflake key pair.
Power BI treats the semantic model data source and the shareable cloud connection as separate objects. In the semantic model's Gateway and cloud connections settings, I would verify that the Snowflake source explicitly Maps to the intended shareable cloud connection. Microsoft documents that mapping here: Connect to cloud data sources in Power BI.
The fact that some models refreshed successfully with the same connection while others failed, then recovered without a credential change, makes a permanently invalid key pair less likely. It is more consistent with a transient binding/connection-resolution issue, although I don't think there is enough evidence to call that the confirmed root cause.
I would also verify that the semantic model owner has permission to use the shareable connection and that all affected models are mapped to the same connection object rather than Personal/Default connections.
For Snowflake, Key Pair authentication is supported through the ADBC implementation, so I would not switch authentication methods simply because of this error.
One useful newer option is the Fabric REST API for binding semantic model connections. If these models are deployed or republished regularly, explicitly validating or applying the connection binding after deployment can make that configuration deterministic.
If this happens again while the mapping still shows the correct shareable connection, I would capture the semantic model ID, connection ID, refresh timestamp/request details and raise it with Microsoft Support. I couldn't find a documented known issue for this exact intermittent Key Pair scenario.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
Resolver IIHi julsr,
Both replies above have the shape of it, and your own line that some models refreshed on the same connection at the same moment others failed is hard to square with a credential or binding problem, which would be stable. I would add something on your third question, since prevention is the part that has not really been answered yet.
Power Automate triggers these through the Power BI REST API, and that path behaves differently from a scheduled refresh in a way that matters here. On the enhanced refresh endpoint the retryCount parameter defaults to 0, so an API-triggered refresh gets exactly one attempt and then stops. Microsoft's refresh troubleshooting guidance says to add automatic retry for custom refreshes if you use XMLA or the REST API, and to use a retry-with-backoff pattern. So for a failure that clears by itself inside an hour, the missing piece is a retry rather than a connection change.
Two practical things. If your workspace is on Premium, PPU or Embedded, you can swap the Power Automate action for an HTTP call to the enhanced refresh endpoint and set retryCount there, which is a lot less work than building the loop in the flow. If it is not, put the retry in the flow itself.
Before you change anything though, you can confirm which mechanism actually failed. Pull the refresh history over the API and look at refreshType on each entry, which reads OnDemand, Scheduled, ViaApi or ViaEnhancedApi. If the failures are all ViaApi and your scheduled runs were clean through the same window, that tells you the binding was fine and the flow simply had no second attempt.