Forum Discussion

GQ00's avatar
GQ00
Icon for Helper III rankHelper III
2 months ago
Solved

Efficient development with lean reports and huge Semantic Model

We currently have a semantic model (import mode) with incremental refresh in the cloud and build lean reports on top of it.

The end result is that when editing the SM one needs to open PBIX-base edit it and push changes via ALM toolkit
When editing reports visual directly via PBIX-reports (which are connected to the SM in the service)
When adding new measures we create them via Tabular editor in the cloud SM directly.

 

Because it is connected to the SM, the lean report PBIX shows no data preview, lacks TMDL for bulk editing, and calculation groups and parameters management is time consuming.

There has to be a more efficient way of doing this, something along the lines of PBIP + Git sync right?

 

Can someone give me a few pointers on where to start this journey? I'm currently going through the MS modules, and we have set up a Git sync from the production workspace. I just learned we could be editing the SM in the web browser instead, which is a plus, but still need to sync those changes to the PBIX-base since the cloud UI does not allow adding extra sources due to incremental refresh policies.

 

Copilot said - 

 

Best overall: PBIP + TMDL + Git + deployment pipeline
This is the cleanest modern workflow for team development because PBIP is text-based, source-control-friendly, and supports CI/CD; it also separates semantic model and report definitions, which removes a lot of the “which file is current?” chaos. [learn.microsoft.com], [learn.microsoft.com]
How it works

Semantic model lives in repo as TMDL/PBIP files. [learn.microsoft.com], [community....rosoft.com]
Thin reports live separately in repo as report definition files. [learn.microsoft.com]
Developers edit the model with either:

Power BI Desktop in PBIP mode, or
Tabular Editor against files / TMDL, or
web TMDL/model editor for quick edits. [learn.microsoft.com], [community....rosoft.com], [learn.microsoft.com]


Deploy through Fabric Git integration / deployment automation rather than manual ALM pushes. Microsoft-backed fabric-cicd exists specifically to deploy PBIP/Fabric items from source control. [learn.microsoft.com]

Why this is better

One source of truth. [learn.microsoft.com], [tabulareditor.com]
Easy diffs and PR reviews for measures, relationships, roles, etc. because model metadata is text, not trapped inside PBIX. [learn.microsoft.com], [community....rosoft.com]
Report and model can evolve independently without stomping on each other.

 

As usual, thanks for your assistance, highly appreciated.

  • Hi GQ00,

    Thanks for the update, and I'm glad to hear the deployment is now working.

     

    Deployment pipelines maintain connections between dependent items through Autobinding. For Autobinding to succeed:

    • The semantic model that the report depends on must exist in the corresponding target stage.
    • If the dependent semantic model isn't present in the target stage, the deployment fails. In such cases, you can use Select related to deploy all dependent items together.
    • You can also use View lineage to verify that the report is connected to the expected semantic model before deployment.

    For more information, please refer to the following documentation:
    The Microsoft Fabric deployment pipelines process - Microsoft Fabric | Microsoft Learn

     

    If you continue to experience the issue after verifying these points, please let us know and we'll be happy to assist further.

     

    Thank you.

12 Replies

  • Hi GQ00,

    The path you are leaning toward is the right one. The cleanest move is to convert your PBIX-base to PBIP (File > Save As > .pbip), commit the resulting .SemanticModel and .Report folders to a Fabric workspace via Git integration, and from there edit the model as TMDL in VS Code or Tabular Editor instead of clicking around in Desktop. Your incremental refresh policy is preserved inside the TMDL definition, so going to PBIP does not break the partitioning logic.

    For deployment, drop ALM Toolkit in favor of either Fabric Git integration plus deployment pipelines (dev to test to prod), or Microsoft's open source fabric-cicd Python library if you want full CI/CD from Azure DevOps or GitHub Actions. Thin reports stay as separate .Report folders next to the model, so report devs can iterate without touching the model.

    A few small gotchas: turn on the PBIP and TMDL preview features in Power BI Desktop options before saving, and once you are on PBIP, the web modeling view becomes much more useful for quick edits since you can pull those changes back into Git too.

     

    If this helped, a thumbs up and accepting the solution would be appreciated.

     

    Best,
    Shai Karmani

     

    Let's connect in LinkedIn

    • GQ00's avatar
      GQ00
      Icon for Helper III rankHelper III

      hi Shai_Karmani , thanks for your answer very useful

       

      I managed to some things going , but now when syncing from repo to bi service , the services seems to be editing the connection string automatically 

       

      seems that the service replies on a relative file path (begging the source connecting with Dot dot ) while my local file is connected to the bi semantic model in Dev workspace 

       

      deployment pipelines map this correctly auto binding works ( thanks to help of parry2k ) but the issue remains 

       

      fabric modified the data source of the report , flagged as changed for cicd 

       

      has anyone experienced this ? how do you work around it?

  •   

    Copilot's right. PBIP + TMDL + Git fixes all of it.

     

     

    • Save the model as PBIP, it becomes TMDL text you can bulk-edit and diff.
    • Keep thin reports as separate PBIP files in the same repo.
    • Deploy via Fabric Git or fabric-cicd, drop the manual ALM pushes.

       

       

    GQ00

    • GQ00's avatar
      GQ00
      Icon for Helper III rankHelper III

      hi Kedar_Pande ,

       

      thanks for your answer.

       

      I recently came to the conclusion that our reporting assets (semantic model and lean reports) should exists in a PPU workspace, this is because of the high CU consumption during report usage (I'm talking about two users throttling an F16 workspace exclusively dedicated to reporting within minutes).

       

      Am I correct in saying that Fabric Git requires a fabric workspace? and if so, can you suggest how to work around this limitation, incorporating CI/CD while maintaning the reporting assets in PPU?

       

      thanks,

       

      *EDIT* Perhaps Git to Dev WS (fabric), and deployment pipeline to Prod WS (PPU) ?
      Should there be a more striaghtfoward way? Am I missing something?

  • v-abhinavmu's avatar
    v-abhinavmu
    Icon for Community Support rankCommunity Support

    Hi GQ00,

    Thanks for reaching out to the Microsoft Fabric Community forum.

     
    Your understanding is correct. Fabric Git integration is currently supported only for workspaces backed by Fabric capacity, so a standalone PPU workspace cannot be connected directly to a Git repository.


    In this scenario, a common approach is to use a Fabric-backed Development workspace for PBIP/TMDL development and Git integration, then promote the validated changes to your PPU Production workspace through a deployment pipeline or an automated CI/CD process. This lets you maintain source control and collaborative development while keeping your production reporting assets in PPU if that best suits your workload.


    Therefore, your proposed workflow Git → Fabric Dev Workspace → Deployment Pipeline/CI-CD → PPU Production Workspace is the recommended approach.

     

    You can also refer to the Microsoft documentation on Fabric Git integration prerequisites for more details: 
    https://learn.microsoft.com/fabric/cicd/git-integration/git-get-started 

     

    I hope this helps. Please feel free to reach out if you have any further questions.
    Thank you.

     

     

    • GQ00's avatar
      GQ00
      Icon for Helper III rankHelper III

      hi , thanks for your answer 

       

      I ended up with 3 WS , Dev (fabric with git) test and prod 

       

      the issue now is that deployment pipelines deploys reports that are linked to the prod semantic model. I thought they would natively know they are suppose to connect to the model in their deployment stage.

       

      I've looked into this further and it seems auto binding failed and that I need to figure something out with semantic links ? please tell me there is an easier way feels that connecting to the SM in their workspace should be the default behaviour.

       

      thanks for your help 

  • GQ00 can you make sure thin report in the dev workspace is connected to the SM in the DEV workspace, and once you promote that to the next workspace, it should auto-bind to the respective workspace. This is a pretty common scenario and always works.

    • GQ00's avatar
      GQ00
      Icon for Helper III rankHelper III

      Hi,

       

      Thanks so much for your help. I can confirm adjusting the data source on the thin reports, syncing to GIT, pulling from Dev and then running deployment pipeline fixed autobinding in Test (test thin report targets test SM).

       

      However I now have another issue hopefully you can help me with. When looking at the comparison between test and prod in deployment pipelines, the semantic model is flagged as New in Test and Not in previous starget in Prod, despite having the same name. I'd rather avoid deleting the SM from prod as it contains several years of data; is there a way to fix this binding between Test and Prod now?

       

      Thank you!

       

      EDIT: Quick google search suggested reassigning the prod workspace to the deployment pipeline, however that did nto fix the issue. Please note the SM in prod is also referenced in pipelines, as such I'm hesitant to delete it. How can I tell DP that SM in Test shoudl be link to the SM in prod ?

       

      TIA

       

      EDIT2: DP is now linking the SM correctly. Deploying end to end was a success, THANK YOU!

      • GQ00's avatar
        GQ00
        Icon for Helper III rankHelper III

        Yet another update, it seems changing branhces in Dev breaks autobinding again... is that the same experience everyone is having? Are we not meant to change branches despiten the fabric UI allow it?

  • v-abhinavmu's avatar
    v-abhinavmu
    Icon for Community Support rankCommunity Support

    Hi GQ00,

    Thanks for the update, and I'm glad to hear the deployment is now working.

     

    Deployment pipelines maintain connections between dependent items through Autobinding. For Autobinding to succeed:

    • The semantic model that the report depends on must exist in the corresponding target stage.
    • If the dependent semantic model isn't present in the target stage, the deployment fails. In such cases, you can use Select related to deploy all dependent items together.
    • You can also use View lineage to verify that the report is connected to the expected semantic model before deployment.

    For more information, please refer to the following documentation:
    The Microsoft Fabric deployment pipelines process - Microsoft Fabric | Microsoft Learn

     

    If you continue to experience the issue after verifying these points, please let us know and we'll be happy to assist further.

     

    Thank you.

  • v-abhinavmu's avatar
    v-abhinavmu
    Icon for Community Support rankCommunity Support

    Hi GQ00,

    I wanted to check if you had the opportunity to review the information provided. Please feel free to contact us if you have any further questions. 


    Thank you.

  • v-abhinavmu's avatar
    v-abhinavmu
    Icon for Community Support rankCommunity Support

    Hi GQ00,

    May I check if this issue has been resolved? If not, Please feel free to contact us if you have any further questions.


    Thank you