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

[bmilian]

Data Model editing on the service is great, but we are missing this ability in Embedded. Are there any plans to make this available ?

[emlisa]

Thank you for this feedback, this is helpful as we prioritize our backlog! Supporting data model editing in Embedded is part of our long term strategy, however this is not something we currently are planning to support in the next few months. 

[MrKETATA]

Honestly, edit dataset in PBI Service, by addning new datasources is a straighforward need and a must ...

When will we have the chance to see it happening ..

[emlisa]

Thank you for taking the time to provide this feedback, this is insightful for us to know what scenarios are most important to users like you. Supporting new datasources is part of our long term roadmap. Supporting this full functionality requires signficiant engineering efforts and will take time to support. In the meantime I encourage you to stay updated on improvements to this previous in our monthly Power BI blog, that is where we will announce new functionality to editing data models on the web including adding new datasources. 

[NOAHSWANSON]

Add a view only mode and prompt users before making or committing changes!

I have been using it in one workspace but I worry about enabling the feature anywhere else because it is like a loaded weapon with the safety off.  There is no warning or way to avoid saving accidental changes.

[emlisa]

Thank you for providing this feedback around your desire for a view-only mode! Currently we provide a warning banner about the autosave experience stating "Keep in mind your changes will be permanent and automatically saved." Your input on the potential benefits of a view-only mode for offering extra caution and preventing unintentional changes is valuable as we focus on enhancing this user experience.

[NOAHSWANSON]

Sorry, yes the initial warning is there, but after that, any changes are just committed whether breaking or not have no alert or "are you sure you want to make a change warning".  Adding either a save button to commit changes, a warning prior to each change being saved with option to cancel etc would be helpful.   In testing this initially with one additional user, it took 10 minutes before I had to reload a model from saved file.  

[emlisa]

Thank you for this insightful feedback! We are actively working on strategies to help enhance this save experience and support simple ways to allow users to recover to a previous point before a change is made. I hope these long term changes help address your concerns!

[GlenW]

+1 to saving vs'non automatic' change or view only mode. This is super cool, but its too risky to enable on Production environments where someone could quite easily break production reporting. 

I really like the ability to look at/modify measures and columns though. Once it's locked behind a save button, I could see this being super helpful for our Data Self Serve strategy.

[emlisa]

Thank you for sharing this feedback! Would supporting a way to recover to a previous state with something like version history help address these concerns you have regarding breaking production reporting? Additionally if we were to support a view only mode do you anticipate many users you work with wanting to have view-only access to the model but make not make any edits?

[GlenW]

echoing @sasdfasdfsad , having previous state to recover to would be a serious plus. Even better would be named version history where we could version and if someone accidentally saved we could see when someone accidentally saved it vs an intentional versioned change. the thing I worry about is having users edit the model without realizing it and then reports break without it being obvious what changed or when.

Our other usecase would benefit from view only mode that allows you (viewers, not just Members) to see the model and the DAX calculated columns and measure. 

[emlisa]

This is helpful feedback as we are prioritizing solution to address these concerns, thank you for taking the time to share this with us!

[sasdfasdfsad]

Having a "view only" mode and a specific way to assign people with this permission would be WONDERFUL.

About 50% of our standard users request to see the calculations and DAX used for our measures, so being able to view all of that (but not edit) would be very helpful for us.

A version history would also be PERFECT.  Then we could see the last few changes made, undo a mistake, and see who last made the change.

[emlisa]

Thank you for sharing this feedback! This is really helpful as we plan and prioritize improvements to this experience. 

[hannibalmads]

Like I mentioned before and as I read what GregW asks for, is to be able to open the data model, make multiple changes and then Save or Discard the changes just like in 99% of Microsoft's applications and forms. If you insist on Auto-saving as is, then at least provide an undo functionality. 

[emlisa]

Thank you for providing this feedback! With an auto-save experience would you be more concerned about wanting to undo changes made in the same editing session or across several editing sessions?

[NOAHSWANSON]

It would be great if git integration could be used for this.  Allow a pr to be staged on the changes and for the user to choose to push or not. 

Sadly for our org we have multiple tenants involved and can't use git integration for workspaces until enhancements are made to better support complex enterprise orgs.  

[emlisa]

Thank you for this feedback, this is helpful to know what scenarios are most important to users like you! What enhancements are needed to git integration for workspaces in order for your org to adopt using this capability? 

[NOAHSWANSON]

My ADO and PowerBI are in different tenants.  I cannot sync a workspace in my premium capacity to a GIT repo tied to an ADO project in a different tenant.  Currently, based on documentation and the testing I have done, the GIT repo and the PowerBI capacity have to be in the same tenant (I created a new ADO org in the same tenant as the power bi capacity and it worked, but we want our code in one place and need to be able to support power bi capacities in multiple tenants and creating pipelines to clone an ADO repo to a different tenant seems hacky at best).  Large enterprises often end up with multiple tenants for a multitude of reasons and while I get it for initial release it would be really nice to support some of these complexities that come with scale.

The solution that comes to mind is allowing syncing on a git repo based on URL instead of the prepopulated drop down list.  

[Kgirgenti1795]

This feature has significantly reduced the time I spend making modifications to my main DataSet file. I have 1 PBI dataset that houses all data transformations, calculated columns, and measures. This one file fuels 20+ reports. It is REALLY nice to make formatting changes right there in the serice and have my in progress report reflect that change within 5 minutes. It is also convenient to be able to view or modify my original formulas, without having a massive dataset file open on my PC then saving it/uploading it to see the result.
This change has pushed me away from relying on hard copy files and feeling confident that I can download a refreshed version of my dataset every morning and it has all the small changes anyone made in the service the prior day.
Like some others, I still like to maintain my own version history to keep record of large changes and have the ability to quickly revert them if necessary, since there is no way to test the service reports reaction to major changes aside from setting the whole thing live then having a pre-change version ready to deploy in the event certain visuals are no longer functioning. If PowerBI could store a version history of published datasets, similar to Sharepoint files, this would be very helpful. Add a version notation feature too, and my life would change.

[emlisa]

We appreciate you taking the time to provide feedback! It brings us great joy to learn that the feature has considerably reduced the time you spend modifying your dataset. We hope it continues to save you time in the future as well! Additionally, thank you for sharing your thoughts on the need for version history for published datasets. Your feedback was very insightful as we are investigating options to help support these types of scenarios in the future. Please continue to let us know any additional feedback you have as you continue to use this feature!