Share your thoughts on the new data model editing in the Power BI service feature (preview)

[emlisa]

Hit Reply to tell us what you think about the new Data Model Editing in the Power BI Service feature so we can continue to improve.

For example:

• What changes would you like to see?
• If you turned off the Workspace level preview switch, why?
• If you turned off the admin switch, why?
• Any suggestions for additional settings or capabilities?

Thanks,

-Power BI team

To read more about the feature see the announcement in the Power BI Product Blog

[emlisa]

We are aware that online editing does not work for datasets in embedded workspaces. Supported embedded workspaces is something we have discussed, however there are not currently plans to support embedded in the near future. Thank you for sharing this feedback, this is helpful as we shape our roadmap and plan improvements that would be most helpful for users like you!

[Kaze]

Thank you so much for the wonderful update! I've been waiting for this feature for long time since it was announced in the release plan.

While this is a very promising feature, it doesn't actually solve a problem I was expecting this feature to solve. That is, once I upload a dataset to the Power BI Service and modify it via XMLA endpoint or set incremental refresh, there's no way to edit the data model other than through 3rd party tools (like Tabular Editor or ALM Toolkit). These types of datasets are no longer downloadable as pbix files, and it's actually preferable because as an IT team I don't want users to be able to download the datasets that contain a lot of confidential data (close to 1GB in size) so easily, but I DO want them to be able to define new measures or calculated columns as they need for their business, without using 3rd party tools and XMLA tools that require learning technical skills. If this feature is applicable to these types of datasets, it will reduce a lot of the pain I have in managing datasets.

[emlisa]

Thank you for this feedback! We currently do not support editing data models in the Service that have been modified via XMLA endpoint or have incremental refresh. However, hearing feedback like this on scenarios that are important to users like you is helpful as we make plans and priorities for future capabilities for this experience. 

[Fabriculous]

Our organization (mid-sized municipality) is similarly positioned. Our datasets are large enough that incremental refresh is the only viable way to fully load them in a reasonable amount of time. We are different from the above example in that we do want to strictly govern measure and column definitions, such that we can endorse a model's re-use while ensuring that reports created by business users are accurate in what they depict.

While the Tabular Editor and ALM Toolkit are invaluable with the current state of incremental refresh, our development team finds itself continously trying to 'sync up' a .pbix file with the service-deployed model so that we can leverage the intellisense-style capabilties of the PowerQuery and DAX editors in Power BI Desktop.

While expansion of the service-hosted editor would be welcomed, I'd equally welcome expansion of Power BI Desktop to be pointed at service-deployed models for modifications (or even partition management, refresh, etc).

[hannibalmads]

I would turn it off as long as there is no version control, no undo, no save. You risk losing your work in an instant. At least you can save/discard while editing the report layout (the visuals) in the service. For the dataset this is a no go in my opinion. 

[emlisa]

Thank you for the feedback! This is helpful to know that no option for version control, undo, or save will prevent you from adopting this feature. These are scenarios we are actively investigating for future improvements, and feedback like this is helpful as we continue to improve this experience. 

[hannibalmads]

Let me emphasize that while I enjoy the concept of editing the data model in the browser, the feature of "As you make changes to your data model, your changes will be automatically saved. Changes will be permanent with no option to undo." is so counter intuitive and counter productive. OneDrive, Teams, SharePoint all have an automatically save but with the additional Version History. Without that, what you get is save without backup!  

[emlisa]

Thank you for the feedback! Addressing these concerns is something we are actively investigating for future iterations of this preview capability. 

[Jellbrae]

"As you make changes to your data model, your changes will be automatically saved. Changes will be permanent with no option to undo."

Is the "undo" feature (eg. like the applied steps in Query Mode but then on a higher level) still to come in the next few weeks or months or is it something that is not considered? 

[emlisa]

The capability to revert a data model to a previous point in time is something we are investigating supporting for future milestones. This type of functionality will realistically take time to implement and will not land in the near future. Do you anticipate needing to "undo" changes regularly? Do you anticipate wanting to do this more in a single session using functionality like Ctrl+Z, or across sessions using functionality such as version history? We are interested in learning more about your feedback on this topic!

[JoeCronk]

I'm not seeing the option to turn this feature on in our workspaces.  Has this been fully released yet?

Edit your data model in the Power BI Service (Preview) | Microsoft Power BI Blog | Microsoft Power B...

[emlisa]

This has been released to all regions. Are you still not seeing this feature for your workspace? If so what type of workspace are you testing and in what region? The one thing to be aware of is not all datasets in pro workspaces are yet fully supported in the following regions. Information about this limitation will regularly be updated in our documentation found here: https://learn.microsoft.com...
Brazil South
Canada Central
Central US
East US
East US 2
India Central
Japan East
North Central US
North Europe
South Africa North
South Central US
Southeast Asia
UAE North
UK South
West US
West US 2

[Kajkoo]

Hello @emlisa , I also don't see this option yet for our premium workspaces. I'm located in Czech Republic (Central Europe).

Any advices how to turn this on?
Thanks

[emlisa]

Thank you for bringing this to our attention! This should be available in all regions for Premium workspaces, we will investigate if there are any issues. 

[JoeCronk]

I'm still not seeing this option.  We are using a Premium workspace and I'm based in North America.

[emlisa]

I am sorry to hear that you do not see this option, do you still not see the workspace setting? This is publicly available in North America regions.

[JoeCronk]

The option is available now.  It finally appeared for me about 2 weeks ago. 

[emlisa]

Glad to hear this was resolved! Please let us know if you have any additional questions or feedback!

[Fowmy]

hi @emlisa 

I am excited to try this out!

I enbaled the feature as instructed yet, the option "Open Data Model" is disabled for me.

My region is West Europe (Netherlands)

[emlisa · Accepted solution]

I am glad to hear that you are excited to try this out! I suspect that the dataset you are trying to test falls under one of our limitations and that is why the 'Open data model' button is disabled. You can see a full list of our limitations for this experience here in our documentation: Edit data models in the Power BI service (preview) - Power BI | Microsoft Learn

To see which limitation your dataset falls under you can do the following steps:

Hover over the Open data model button in the dataset details page. This displays a tooltip indicating which limitation is causing the Open data model button to be disabled.

[arpost]

I love being able to edit semantic models in the Service as that makes it much easier to manage centralized models. That said, I've found you can't use this feature with the Fabric Data Warehouse as some tables that get added are broken when you add them.

What's odd is not all tables have this problem; some in certain schemas work just fine while others fail. Is this being addressed?

Here's my community post about this behavior (link).