CI/CD inconsistency for Power Bi Reports

Hi Shivek,

Thank you for responding and assistance. I'm using Fabric REST APIs to achieve the deployments to UAT environment. 

1. I verified that deployed semantic model in bi-uat is connected to lakehouse in data-uat and there were no warnings too. During the run time, it automatically replaces ( using powershell) the workspace id and lakehouse id with actual ids of uat. Hence it is showing the right lakehouse of uat.

2. I verified too the report in bi-uat is bound to UAT semantic model. I used the below command to check and it shows the correct listings.

 fab api -A powerbi "groups/${{ vars.UAT_BI_WORKSPACE_ID }}/reports" --show_headers

3. I'm using Managed Identity that has contributor access to both workspaces which are data-uat and bi-uat.

4. Yes I'm using a single yml file that has two jobs, job-1 will deploy semantic model, refresh semantic model, sleep for 30 sec, and job-2 executes and will deploy reports.

I think I may be missing something for this report behaviour, but could not identify where exactly this is causing the issue.

Just to give you my current deployment process. The CI (build) is, it will just create and upload the entire code as artifact

The CD (deploy) is, it will download the artifact and replaces the workspace id and lakehouse ids of dev with UAT ids and then performs the deployments.

Appreciate your help if there is anything that I could check to bring down the issue to closure.

Hi Shivek - Thank you for responding and assistance.

I'm using Fabric REST APIs  (fab deploy) to achieve the deployments to UAT environment.

1. I verified that the deployed semantic model in bi-uat is connected to lakehouse in data-uat and there exists no warnings too

2. I did perform the following command to check if the report is bound to semantic model in bi-uat and yes it is connected to the right semantic model

fab api -A powerbi "groups/${{ vars.UAT_WORKSPACE_ID }}/reports" --show_headers

3. We use only a single YML file that has 2 jobs, job-1 will deploy semantic model, refreshes semantic model. Job-2 will deploy reports.

4.I'm using Managed Identity that has contributor access to both workspaces, data-uat and bi-uat.

Just to give you the current process approach. The CI (build) is, will upload the code as artifact. The CD (deploy) is, will download the artifact, replace the workspace id and lakehouse id of dev with UAT ids and deploy 

I'm not able to identify which is causing this issue, but I believe there is something thatbis causing this issue.

Appreciate your help if there is anything I could check to fix this issue.

Hi Shivek - Thank you for responding and assistance.
I'm using Fabric REST APIs (fab deploy) to achieve the deployments to UAT environment.
1. I verified that the deployed semantic model in bi-uat is connected to lakehouse in data-uat and there exists no warnings too
2. I did perform the following command to check if the report is bound to semantic model in bi-uat and yes it is connected to the right semantic model
fab api -A powerbi "groups/${{ vars.UAT_WORKSPACE_ID }}/reports" --show_headers
3. We use only a single YML file that has 2 jobs, job-1 will deploy semantic model, refreshes semantic model. Job-2 will deploy reports.
4.I'm using Managed Identity that has contributor access to both workspaces, data-uat and bi-uat.
Just to give you the current process approach. The CI (build) is, will upload the code as artifact. The CD (deploy) is, will download the artifact, replace the workspace id and lakehouse id of dev with UAT ids and deploy
I'm not able to identify which is causing this issue, but I believe there is something thatbis causing this issue.

Appreciate your help if there is anything I could check to fix this issue.

Hey - This is fixed. The problem is that I was checkign with user does not have enough of permissions

Hi mohan072​,

Thanks, that helps. If the semantic model in bi-uat is definitely connected to the Lakehouse in data-uat, and the report is also bound to the correct UAT semantic model, then I would stop looking at binding for now.

The next thing I would isolate is whether the semantic model itself is healthy after deployment.

Since you are using the REST APIs, one thing worth checking is the refresh sequencing. A semantic model refresh request is asynchronous, so the API call succeeding does not necessarily mean the refresh has finished successfully. Microsoft documents this under enhanced refresh with the Power BI REST API.

I would make sure Job 2 does not deploy the reports until the UAT semantic model refresh status has actually reached Completed, rather than just continuing after the refresh request was accepted.

I would also try a very simple DAX query directly against the UAT semantic model using the Execute Queries REST API.

Something as simple as:

EVALUATE TOPN(10, 'YourTable')

If that fails, then the report is probably only exposing a semantic model/data-access problem underneath it.

If the DAX query succeeds but the report visuals still fail, then I would compare the deployed report definition with Dev next, because at that point the model, Lakehouse connection and data path have all been proven independently.

One other thing I would check if this is Direct Lake is the identity being used when the model queries the Lakehouse. Microsoft notes that Direct Lake access can depend on either the report user having ReadData on the Lakehouse or the semantic model using a fixed identity with access to the source. Simply giving the CI/CD identity Contributor access does not necessarily prove that the runtime query identity has access. The Fabric permission model.

So my next three checks would be:

1. Confirm the semantic model refresh actually reaches Completed.
2. Execute a simple DAX query directly against the UAT semantic model.
3. If it is Direct Lake, verify the runtime identity/connection has access to the UAT Lakehouse.

That should tell us whether the failure is still in the semantic model layer or genuinely only in the deployed report.

AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.