When you load a dimension table (say a calendar table) in Power BI desktop, there are often lots of numeric columns that are not additive. Examples include Year, Month Number, Day of Week etc. By default (unless you set the data type to text) these numeric columns will have the default aggregation behaviour set to SUM. But they are not additive (of course). It would be much better to set these (dimension numeric columns) as "do not summarize". This could be managed in various ways that would be better than the current state. eg, you could simply mark all numeric columns in a calendar table as "do not summarize" by default and allow the user to change truly additive days (like isWorkingDay) to SUM when required. Even better, use the AI capabilites of Azure to work it out.

This idea was mentioned by Jeffery Wang in a meeting at the end of the MVP Summit 2019. No doubt Jeffery has his own ideas of how to execute this. It is a great idea and would add a lot of value to the majority of users.

Microsoft case 119083024001340 was filed for an issue causing a failure in OData.Feed when reading valid OData metadata. Microsoft Product Group agreed there is an issue but will not fix it unless there is sufficient votes.

The issue occurs if an OData entity, lets call it MyNamespace.E1, has a property named JobStatus and there is also a bound function also named JobStatus that is bound to MyNamespace.E1. In this case, when OData.Feed reads $metadata from the OData API, it throws an exception:
[Expression.Error] The field 'JobStatus' already exists in the record.\r\nStackTrace:\n at Microsoft.Mashup.Engine1.Runtime.KeysBuilder.Add(String key).

Again, just to be clear, Microsoft Product Group agrees this is an issue in OData.Feed where they cannot handle duplicate column names that would be created from both property and bound function. I suggested they just append a "function" string or similar to the end of the JobStatus function (rename JobStatus to JobStatusfunction) to eliminate the duplicate name. Microsoft will not do this unless there is sufficient votes.

Please vote!!!
Thanks,
Dave

Currently, all data sources in a Power BI report/dataset, that are not on cloud, must be available in a single Gateway to work.

But if the datasources in the report are coming from different Gateways, that doesn't work. It is not possible to combine them for refresh.

Say I have a Sales Report. It connects to DB A, B and C.

DB A and B is configured in Gateway X
DB C is configured in Gateway Y.

The report creator have been provided access to all of them.

Now if I try to configure data refresh in PBI Service, it will not work. As none of the Gateway has all 3 DBs. The user can’t connect to DB A and B through Gateway X, and DB C through Gateway Y.

We have to configure all the DBs in the same Gateway to work.

Since in our organization, we have many datasources, and different teams control the access to them, it becomes troublesome, and lots of repetitive data sources has to be created that causes a governance and management headache.

I know this idea was recently (April 2019) shot down by Microsoft, even with over 2,000 votes in favor of it, but I'm bringing it up again. The simple fact is, we are bound by regulations that keep us from using the cloud service, so the on-premise Power BI Report Server is our only option for widespread report distribution. Paginated reports on PBIRS can be subscribed to, which makes the inability to add Power BI reports to subscriptions even more frustrating. This lack of support severely limits our ability to grow acceptance for the platform. I ask that you please reconsider your decision.

Adding few measures to your data model in PowerBI could be easily managed, but what about adding tens or even hundreds of measures! Organizing those measure into categories using folders could help a lot.

To show you what I exactly mean, I will demonstrate the alternative way to create those folders using empty tables:

1. Select "Enter Data" from the Home ribbon > Change the column name to "Id" and choose the table name e.g. "_Financial Measures" (Create all the tables)


2. Select "New Measure" from the Modeling ribbon (Or choose any shortcut) > Type and create a new measure e.g. Total Sales = SUM(Sales[SalesAmount])


3. Select the created measure in the "FIELDS" pane or just click inside the formula bar > Open the "Home Table" list from the modeling ribbon and select a table


4. When done, right-click on the "Id" columns and select Hide


5. Now, Power BI will change the Icon from Table to Measures. How nice!

Happy PowerBI-ing,

The current setup of Build Permission is too extensive and I see a need to find a middle ground in terms of data access permission. What I (and I assume others) need is a middle-level configuration where users cannot build new reports on the dataset (including analyze-in-excel), but can still use Export to Excel based on pre-configuered visuals. This way the developer can control what data granularity or filter is available to the consumers.

This ties in to existing requests to disable Analyze-in-Excel feature specifically, and now expands into the broader scenario of Build Permission and shared datasets.

Related post in the Issues forum:
https://community.powerbi.com/t5/Service/Export-Data-from-Visual-without-Build-Permissions/m-p/734470#M71708

Related Idea for analyze-in-Excel:
https://ideas.powerbi.com/forums/265200-power-bi-ideas/suggestions/20487199-disable-analyze-in-excel-feature-without-disabling
https://ideas.powerbi.com/forums/265200-power-bi-ideas/suggestions/34275706-tenant-settings-export-data