Forum Discussion
Daily refresh fail: employee leaves org
hello,
We are facing a situation where the owner of a Power BI semantic model has left the organization, and as a result, the scheduled daily refresh has stopped.
For context: There is no on-prem, gateway, VPN involved, The data source is a third-party SaaS service (Google Analytics GA4),
Could someone please point me to official Microsoft documentation (or the likes) that explains the recommended, long-term best practice to make scheduled refresh resilient in such scenarios?
While another user in the organization can take ownership, update the credentials, and resume the refresh, this feels like a temporary fix. Is there a more permanent, future-proof solution to prevent refresh failures when the original model owner leaves?
I came across previous discussions and am confused about the difference between:
- Creating an Azure AD App and using a Service Principal
- Using a Service Account
but most of them seem very old posts, and seem very complicated (making an app etc.)
Thankyou, cengizhanarslan and rohit1991 for your responses.
Hi vibhoray
We appreciate your inquiry through the Microsoft Fabric Community Forum.
A service account is technically just another Entra ID (Azure AD) user account, but it is created for system use and not tied to any individual employee. Because it belongs to the organization and is managed by IT, the credentials and access remain stable even if employees leave. This makes it suitable for things like Power BI dataset refresh, since the authentication is not dependent on a specific user account that might get disabled later.Thank you
5 Replies
rohit1991Super User
Hii vibhoray
The refresh failed because the semantic model was using credentials tied to the original owner’s user account (OAuth). When that account is disabled after the employee leaves, Power BI can no longer authenticate to the data source, so scheduled refresh stops. The recommended long-term best practice is to configure the data source using a Service Principal (Azure AD App) or a dedicated service account, so authentication is not dependent on an individual user. This ensures the dataset refresh continues even if employees leave and aligns with Microsoft’s governance recommendations for enterprise environments.
- cengizhanarslan
A service account is just a regular Entra ID user account (licensed if needed) that:
-
isn’t tied to a single employee
-
has stable MFA/CA rules
-
is owned/managed by IT
-
is used specifically for Power BI refresh authentication
This is the most practical approach because many SaaS Power BI connectors only support user OAuth sign-in, not app/service principal sign-in.
-
thank you for feedback... it seems " dedicated service account" will be better option.
Does it differ in anyway (technically) than my our own personal account ([email protected])
OR, did I understand correctly --> it's just another user account (with user login email, password etc.), provisioned in a same way as IT would do when new employee join... ? the risk still remains, if somone forgets the password to this suer/service account...
Thankyou, cengizhanarslan and rohit1991 for your responses.
Hi vibhoray
We appreciate your inquiry through the Microsoft Fabric Community Forum.
A service account is technically just another Entra ID (Azure AD) user account, but it is created for system use and not tied to any individual employee. Because it belongs to the organization and is managed by IT, the credentials and access remain stable even if employees leave. This makes it suitable for things like Power BI dataset refresh, since the authentication is not dependent on a specific user account that might get disabled later.Thank you
thak you all for feedback.
It's clear now. "Service Account" is just another regular user account. but becaue it's lifecycle is supervized under IT for, for specific purpose ---> it's lifetime if more predictable, sustainable.
I got confused with similar accounts in "Google GCP", where they're also Service Account (Client ID + Server, Crednetials), https://docs.cloud.google.com/iam/docs/service-account-creds
but looks like in Microsft universe "Service Principle" come more close to what's also called "Service Account" in GCP universe..
