Join us at FabCon Atlanta from March 16 - 20, 2026, for the ultimate Fabric, Power BI, AI and SQL community-led event. Save $200 with code FABCOMM.
Register now!The Power BI Data Visualization World Championships is back! It's time to submit your entry. Live now!
Solved! Go to Solution.
You want to make sure you have separated off your power bi report layer (https://m.youtube.com/watch?v=PlrtBm9YN_Q) and then as @lbendlin suggests use the xlma end point. Everything you can do with on prem SSAS is there. I connect to my model using tabular editor but you can use visual studio. Only use power bi desktop for report visual design. Everything else sits in tabular editor/visual studio.
You want to make sure you have separated off your power bi report layer (https://m.youtube.com/watch?v=PlrtBm9YN_Q) and then as @lbendlin suggests use the xlma end point. Everything you can do with on prem SSAS is there. I connect to my model using tabular editor but you can use visual studio. Only use power bi desktop for report visual design. Everything else sits in tabular editor/visual studio.
Ok, this can work. So I'll have to change measures in the Visual Stusio / Tabular Editor and deploy only metadata. And the Visuals I need to change in the reporting .pbix file....
Then it means I have to make changes in two places, but still a possible solution, thanks.
What about Pipelines? Can that work?
I suppose I've always seen it as separate concerns rather than making changes in two places. I work on a central data model in tabular editor/VS just as I would do with an on prem SSAS instance (Microsoft describe power bi premium/premium per user as being a superset of azure analysis services).
Then I consume that data model in power bi reports, excel etc.
I think deployment pipelines would work though. Only thing you have to watch is if you make a certain changes to the model (relationships/calculated columns) you then need to connect to the xlma end point and force a recalculation at least if you don't do a full refresh.
>> Only thing you have to watch is if you make a certain changes to the model (relationships/calculated columns) you then need to connect to the xlma end point and force a recalculation at least if you don't do a full refresh.
Do you have any additional information on how we definitely know when this is required and when it is not?
You will know when your users report broken visuals...
"before I deploy I always have to refresh so that when I Publish, the data is up-to-date..."
That is not mandatory. Any meta data update will automatically initiate a dataset refresh anyway.
On Premium you can refresh entire datasets, individual tables (queries) and even partitions (if you use incremental refresh). The refresh request options are the same as in SSAS Tabular (because datasets are in essence the same as SSAS Tabular models).
"Any meta data update will automatically initiate a dataset refresh anyway."
But before it updates in the service, my users will see outdated data for 30 minutes.
This is unacceptable.
But I think I found a way - to use pipelines. I am still reseaching...
You can also use XMLA endpoint requests that allow you to specify exactly what part of the dataset/table/partition should be refreshed. Same as what you can do in regular (tabular) SSAS.
This still doesn't answer my task to deploy only changes to report/measures without having to refresh anything (even incrementally)
With tools like ALM Toolkit you can deploy meta data changes and keep the "old" data.
I am aware of ALM, but it only publishes the changes in the model, such as measures, not changes in visuals.
Did you find a solution to this i.e. publishing only the report changes and not the model changes when using PBIP?
I do see the possibility of doing this with deployment pipelines but can't find an option to just deploy report changes without deployment pipelines.
The only option I can see is to separate the report completely into a separate PBIP file.
The Power BI Data Visualization World Championships is back! It's time to submit your entry.
| User | Count |
|---|---|
| 47 | |
| 43 | |
| 36 | |
| 33 | |
| 30 |
| User | Count |
|---|---|
| 138 | |
| 118 | |
| 59 | |
| 59 | |
| 56 |