my customers love the new column profiling feature in Power Query. With the GA today, it is even better. One thing I have been asked for a few times now is the ability to export the column profile data as the result of a query. Ideally this could be exported to Excel for further investigation, or simply return it to ta table in Power BI for further investigation.

I create a query in Power BI Desktop against a data source. Power BI Desktop insists on executing it multiple (usually three) times. This makes Desktop slow and for back-end data sources exerts additional load that can also incur additional costs.

Note: I am not talking about the scenario where a query is referred to multiple times in M, rather just a simple query loaded into one table in the data model. I assume the engine is checking data types, etc - but the current approach is very slow/painful. Optimisation is needed!

In the field formatting section of a table, allow users to be able to change the data type of the column. Example: I have a custom selected measure that will give the results for both Sales or Units depending the selected slicer choice in a table. I need to have the Sales in currency format and Units in a whole number but cannot have both currently, only one of the other.

We need a way to display data in our local timezone accounting for daylight savings time. The data source stores the dates in UTC but we need reports to show local time. A native and easy way to do this in PowerBI would be a huge help. There are many blog posts and help articles floating around with solutions people have attempted but it's a simple issue that so many users would benefit from having solved centrally by PowerBI itself. Please consider!

All the code generated using the Power Query UI is so literal, it feels like I'm interacting with a dumb kid. If I'm selecting all columns and, say, trimming them, why hard code all the column names? It makes code hard to re-use and brittle, which generates a lot of menial code editing overhead.

Instead I would like PQ to try and generate more generic code. I'm sure combining soft coding with code generation is a hard problem, but this would have so much more impact on the productivity of Power Query developers than sinking resources into yet another sentiment analysis AI solution that hardly anyone uses outside of demos...

All the code generated using the Power Query UI is so literal, it feels like I'm interacting with a dumb kid. If I'm selecting all columns and, say, trimming them, why hard code all the column names? It makes code hard to re-use and brittle, which generates a lot of menial code editing overhead.

Instead I would like PQ to try and generate more generic code. I'm sure combining soft coding with code generation is a hard problem, but this would have so much more impact on the productivity of Power Query developers than sinking resources into yet another sentiment…

There should be an option to disable "see records" for the graphics that support it. It is a huge issue when it comes to security. I know you can hide certain columns but in reports that should only be high level data, the see records item is really an issue.

While renaming query steps (right-click rename OR right-click properties) when you apply the name change, it will re-run the query step. Why? Best practice to rename query steps yet for very large data sets this becomes cumbersome during the queries initial development. Note: I could be missing something valuable that would prevent this, please advise.

Incremental refresh works good when refreshing data from tables. We have to deal with complex logic and predefined structure which is not possible from tables. Incremental refresh from stored procedure will be very helpful.

It would be good to be able to export data that appears in PowerBi visuals in Excel in the format as they are presented. Currently export will retreive the underlying data and not how it has been pivoted/presented within PowerBI.
Benefit of this is that the investment in time to get it ini that format is not wasted (or needs more time to redo in excel) if that data is needed for other teams to use

Have a DisplayAsName at the dataset level for fieldnames so you don't have to rename it all the time for every visual. For example if the fieldname is nc_BPS and you want it to show as "Beipiaosaurus" everywhere, it would be nice to have a DisplayAs option.

Instead of using the generic "Added Custom" or "Added Conditional Column", rather insert the column name to make it easier to navigate through the step logic.

For example if I add a conditional column called Turnaround time, it is far more useful for me to see that I added Turnaround time than for me to see what type of column I added.

It saves time that is waste having to manually rename those steps and also means that if one of my colleagues works on the model, they can easily identify important items without having to go through every addition to find the right one.

I propose that this is only for added columns though as it wouldn't be practical for changes that affect multiple columns like name changes or removals.

Instead of using the generic "Added Custom" or "Added Conditional Column", rather insert the column name to make it easier to navigate through the step logic.

For example if I add a conditional column called Turnaround time, it is far more useful for me to see that I added Turnaround time than for me to see what type of column I added.

It saves time that is waste having to manually rename those steps and also means that if one of my colleagues works on the model, they can easily identify important items without having to go through every addition…

The recently introduced Column Quality feature in the Query Editor allows us to identify Valid, Error and Empty values in each column.

It would be great if we could quickly and easily remove all columns that only contain Null/Blank values.

I recently had a situation where I'd loaded a table containing 100 or so columns into the Query Editor and I had to manually work through these removing all such columns - which was at least half of them.

Having such a feature avaialble in the Query Editor wold be fantastic, and it may also be useful to have something very similar in the Data View which hides all such columns.

The recently introduced Column Quality feature in the Query Editor allows us to identify Valid, Error and Empty values in each column.

It would be great if we could quickly and easily remove all columns that only contain Null/Blank values.

I recently had a situation where I'd loaded a table containing 100 or so columns into the Query Editor and I had to manually work through these removing all such columns - which was at least half of them.

Having such a feature avaialble in the Query Editor wold be fantastic, and it may also be useful to have something…

Recently some Column Quality and Column Distribution checks have been introduced into the Query Editor, which are great.

A useful addition would be identifying Foreign Key values for which there's no corresponding Primary Key. A simple and common example of this would be identifying Customers who appear in the Sales fact table who don't appear in the Customer dimension table.

The join created by the developer would identify the Foreign/Primary Key relationship, and perhaps any such orphaned Fact table records could be highlighted against the join itself.

Currently such occurrences of this will usually result in Sales values posted against blank Customers in reports. The Customer value from the Fact table would have to be brought into the report to identify the missing Dimension table records.

Recently some Column Quality and Column Distribution checks have been introduced into the Query Editor, which are great.

A useful addition would be identifying Foreign Key values for which there's no corresponding Primary Key. A simple and common example of this would be identifying Customers who appear in the Sales fact table who don't appear in the Customer dimension table.

The join created by the developer would identify the Foreign/Primary Key relationship, and perhaps any such orphaned Fact table records could be highlighted against the join itself.

Currently such occurrences of this will usually result in Sales values posted against…

The SAP HANA DirectQuery does not support data prep features like changing data types as well as other formatting changes. Without the ability to prep the SAP HANA data with DirectQuery, there is no way to leverage SAP HANA's real-time data capability. Thus, whenever a user needs to change data, they are forced to use Import (a static data set).

In the current relationship view window we can delete a data table from the model.

It would be nice to right click on the data table and click edit query for the underlying table. This would immediately open up the query editor for data table changes.

Today you have to switch views to the table view, and click edit table. or navigate to the edit queries button and click edit queries. Doing this opens the queries, but you still have to navigate to the table you want to change.

Ready to get started?

Power BI Newsletter

Take your data to the next level with the best tips and tricks from our experts.

Thanks for signing up for the Power BI newsletter.

By clicking Sign up, you are giving your consent to Microsoft for the Power BI newsletter program to provide you the exclusive news, surveys, tips and advice and other information for getting the most out of Power BI. You can unsubscribe at any time.

Downloads

Whether you are on the go or need to create rich, interactive reports, Power BI offers you the tools you need.