Best Practice for Scheduled Refresh Authentication in Power BI with Fabric Lakehouse SQL Endpoint

[aswathyjoe]

I'm a Power BI developer working with data stored in Microsoft Fabric Lakehouse. I connect to the Lakehouse using the SQL endpoint and publish my reports to the Power BI Service.

When setting up scheduled refreshes in the Power BI Service or connect to the cloud datasource in fabric, I'm unsure about the best practice for authentication:

• Should I use a service account?
• Or is it acceptable to use a personal company email account?

I want to ensure the setup is secure, scalable, and doesn't break if someone leaves the organization or changes roles.

Any guidance or documentation links would be greatly appreciated!

[Anonymous]

Hi @aswathyjoe,

Thanks for reaching out to the Microsoft fabric community forum. It looks like you are looking for guidance on what to choose when setting up your schedule refreshes in PBI Service. As @VahidDM has already responded to your query, kindly go through his response and check if your query is answered.

I would also take a moment to thank @VahidDM, for actively participating in the community forum and for the solutions you’ve been sharing in the community forum. Your contributions make a real difference.

If I misunderstand your needs or you still have problems on it, please feel free to let us know.  

Best Regards,
Hammad.

[VahidDM · Accepted solution]

@aswathyjoe 

Use a non-human identity. Don’t use your personal account.

Best practice

• Service principal (preferred): Enable “Allow service principals to use Power BI APIs” and allow specific security groups. Give the SPN Read/Use SQL endpoint (or Viewer) on the Lakehouse item or workspace; grant it Build on the semantic model. Store its secret in the dataset/fabric connection (OAuth2 → Service principal). Rotate the secret regularly (ideally via Key Vault).

• Service account (fallback): If SPN isn’t allowed, use a dedicated Entra user account (no MFA for refresh), licensed appropriately, and placed in a group. Never tie refresh to a personal user.

• Least privilege: Only grant what’s needed (no Admin/Member if not required). Scope access at the workspace or item level; avoid giving tenant-wide rights.

• Operational hygiene: Set dataset owners/contacts to a group, monitor refresh with alerts/audit logs, and document the identity used so offboarding doesn’t break refresh.

Short answer: Use a service principal for scheduled refresh to the Fabric Lakehouse SQL endpoint; avoid personal accounts.