Forum Discussion
Deployment pipelines, data source credentials from contributor not carried on after deployment
My organization has a DEV and PROD workspace, there we have contributors and admins (I'm one of the admins). Everytime a contributor asks me to deploy a dashboard from DEV to PROD the data source credentials settings (e.g. SharePoint) and the refresh settings vanish, that leads to no refresh at all in PROD and after i do manually configure them the data source fails to refresh since most of the times i do not have access to the data.
How do you guys treat this kind of problem? We are migrating from Report Server to Service and this has been a painpoint.
Hi caio-pavesi,
1. Create a dedicated Service Account (easier) or Service Principal (more robust)
A shared service account (e.g. [email protected]) that has access to all data sources (SharePoint, SQL, etc.)
Give it at least Contributor role in both DEV and PROD workspaces
2. Take ownership of semantic models with that account
After each deployment, the service account should Take Ownership of the semantic model in PROD:
Semantic Model → Settings → Take Ownership
This makes the service account the owner, so its credentials are used for refresh.
3. Set credentials once under that account
Since the service account always has source access, you configure credentials once and they persist reliably.
4. Automate with Deployment Pipeline Rules
In your Deployment Pipeline, configure Parameter Rules and Data Source Rules:
Pipeline → Deployment Rules → Data source rules
This lets you remap the data source connection string from DEV to PROD automatically on deploy (e.g. DEV SharePoint site → PROD SharePoint site), so credentials don't need to be re-entered manually.For refresh schedules:
Use the Power BI REST API or Fabric REST API to programmatically restore refresh schedules post-deployment. You can wrap this in a Power Automate flow triggered by a deployment pipeline event:
Deployment completes → triggers a Flow
Flow calls POST /datasets/{datasetId}/refreshSchedule to restore the schedule
Flow calls POST /datasets/{datasetId}/Default.TakeOverInGroup to reassign ownership to the service account
https://learn.microsoft.com/en-us/fabric/cicd/deployment-pipelines/create-rules
https://learn.microsoft.com/en-us/fabric/enterprise/powerbi/service-premium-service-principal
https://learn.microsoft.com/en-us/rest/api/power-bi/datasets/take-over-in-group
https://learn.microsoft.com/en-us/rest/api/power-bi/pipelines/deploy-all
https://learn.microsoft.com/en-us/rest/api/power-bi/pipelines/selective-deploy
Hope this helps! Don't forget to accept as solution ✅ and thumbs up 👍 in order to keep helping others 🙂
Best regards,
Oussama (Data Consultant - Expert Fabric & Power BI)
6 Replies
Hi caio-pavesi,
1. Create a dedicated Service Account (easier) or Service Principal (more robust)
A shared service account (e.g. [email protected]) that has access to all data sources (SharePoint, SQL, etc.)
Give it at least Contributor role in both DEV and PROD workspaces
2. Take ownership of semantic models with that account
After each deployment, the service account should Take Ownership of the semantic model in PROD:
Semantic Model → Settings → Take Ownership
This makes the service account the owner, so its credentials are used for refresh.
3. Set credentials once under that account
Since the service account always has source access, you configure credentials once and they persist reliably.
4. Automate with Deployment Pipeline Rules
In your Deployment Pipeline, configure Parameter Rules and Data Source Rules:
Pipeline → Deployment Rules → Data source rules
This lets you remap the data source connection string from DEV to PROD automatically on deploy (e.g. DEV SharePoint site → PROD SharePoint site), so credentials don't need to be re-entered manually.For refresh schedules:
Use the Power BI REST API or Fabric REST API to programmatically restore refresh schedules post-deployment. You can wrap this in a Power Automate flow triggered by a deployment pipeline event:
Deployment completes → triggers a Flow
Flow calls POST /datasets/{datasetId}/refreshSchedule to restore the schedule
Flow calls POST /datasets/{datasetId}/Default.TakeOverInGroup to reassign ownership to the service account
https://learn.microsoft.com/en-us/fabric/cicd/deployment-pipelines/create-rules
https://learn.microsoft.com/en-us/fabric/enterprise/powerbi/service-premium-service-principal
https://learn.microsoft.com/en-us/rest/api/power-bi/datasets/take-over-in-group
https://learn.microsoft.com/en-us/rest/api/power-bi/pipelines/deploy-all
https://learn.microsoft.com/en-us/rest/api/power-bi/pipelines/selective-deploy
Hope this helps! Don't forget to accept as solution ✅ and thumbs up 👍 in order to keep helping others 🙂
Best regards,
Oussama (Data Consultant - Expert Fabric & Power BI)
oussamahaimoud not sure if this is possible per my company policies but I'm going to give it a shot, for now Thank you for the help!
Ebiexperts WIP can do the auto mapping at every publish.
Hi caio-pavesi
This happens because manual PBIX overwrites or standard workspace pushes completely wipe out the target dataset's credentials and gateway bindings in the Service. The cleanest way to handle this is to have your contributors stop hardcoding their SharePoint URLs or database connections and use Power BI Parameters instead. When you deploy using Fabric Deployment Pipelines, you can set up a deployment rule that automatically swaps the DEV parameter value to the PROD path, which stops the production report from breaking or trying to look back at development files.
To fix the issue where you lack data access, your team needs to transition away from individual personal credentials for production refreshes. Instead, set up a dedicated corporate Service Account that has read access to both the DEV and PROD data sources. Once that Service Account takes ownership of the PROD dataset and authenticates the connection one time, future pipeline deployments won't strip the credentials away, completely removing you as the manual bottleneck.
In my case most of the contributors use Excel Files as source, is it still possible to use the parameters?
Hi caio-pavesi,
Thanks for reaching out to the Microsoft Fabric Community forum.
Data Source Rules can be defined for the following data sources:
- Azure Analysis Services (AAS)
- Azure Synapse
- SQL Server Analysis Services (SSAS)
- Azure SQL Server
- SQL Server
- OData Feed
- Oracle
- SAP HANA (Import mode only)
- SharePoint
- Teradata
"For other data sources, It is recommended" using parameters to configure settings that may change between deployment stages.
Best practices for lifecycle management in Fabric - Microsoft Fabric | Microsoft Learn
The parameters can be used for configurations such as data source connections, internal Fabric items, queries, filters, and text displayed to users. In Deployment Pipelines, Parameter Rules can be configured to set different values for each deployment stage.
You may find the following documentation helpful:
Create deployment rules for Fabric's ALM - Microsoft Fabric | Microsoft LearnI hope this helps. Please feel free to reach out if you have any further questions.
Thank you.
