Skip to main content

Creating Excel “Data Dump” Reports From Power BI

We’ve all met them: the users whose idea of a ‘report’ is a large table of data dumped into Excel. However many beautiful data visualisations they see, however many times you try to convince them of the benefits of using Power BI to build reports, they just want to know where the “Export to Excel” button is so they can carry on analysing data in the same old way. Sometimes there’s a valid reason for doing this, sometimes not, but all too often internal politics means that you have to accommodate them.
If you’re using Power BI the obvious way to do this is to use the “Export Data” button in Power BI. However, as the documentation notes, there are some limits on the amount of data that can be exported:
  • The maximum number of rows that can be exported from Power BI Desktop and Power BI service to .csv is 30,000
  • The maximum number of rows that can be exported to .xlsx is 150,000
What’s more, clicking a button to export data and then copying it into an Excel report is a time-consuming, error-prone, manual process that no-one likes doing.
There is another way to get data from Power BI into Excel though: using the Analyze in Excel feature. Rather than using Analyze in Excel to create a PivotTable, which may suffer from the subtotals issue described here if you aren’t using the click-to-run version of Excel 2016 and as a result may be very slow when dealing with large amounts of data, and which will be awkward to get data out of because you have to use Excel functions like GetPivotData(), in this post I’ll show you how to get data from Power BI into an Excel table instead.
First of all you need to create a PivotTable in Excel on your desktop that is linked to a dataset published to Power BI. You can do this either by clicking the Analyze in Excel option from inside the Power BI service in the browser (see here for how to do this), or by using the Connect to Data option in the Power BI Publisher for Excel add-in.
Next, drag any measure into your PivotTable (you will need to have at least one measure defined in your dataset to do this) like so:
image
Then double-click inside a cell containing values, such as the selected cell in the screenshot above, or right-click on the cell and select Show Details:
image
When you do this a new worksheet will appear with a table in it containing rows of data from a table in the underlying dataset, but the exact data is irrelevant here. The real point is that you now have an Excel table (not a PivotTable) with a connection back to your Power BI dataset and you can edit the query that it uses to return data from Power BI – a variation on an old trick known to SSAS and Power Pivot users. You can now delete the PivotTable you created because you will no longer need it.
On the new worksheet with the table on it, right-click in a cell and select Table then Edit Query:
image
A dialog will pop up, and you’ll see an MDX Drillthrough statement in the Command Text box as shown below:
image
You can replace this statement with any MDX or DAX query you want – I recommend using DAX queries here because they are likely to be easier to write if you already know how to write DAX calculations, and unlike MDX queries they return a tabular resultset. I have a fairly old series of posts on DAX queries here that will help get you going. It will be a good idea to install DAX Studio and write your queries there, then copy them into Excel when you are happy with them.
Once you have a working DAX query in the Command Text box:
image
You can click OK, the query will run and you’ll see the output of the query in the Excel table:
image
One minor annoyance is that the column names will be in DAX ‘Table Name’[Column Name] format, and although you can use the SELECTCOLUMNS() DAX function to alias your column names and thereby remove the table names, the square brackets around the column names will always be there.
There are several good things about this approach to getting data into Excel:
  • It allows you to exceed the 150,000 row limit of the native Power BI Export option mentioned above
  • The queries are very quick to run if you aren’t doing anything complex in them
  • It avoids manual exporting – you just use Excel’s native Refresh functionality to run the query whenever you want to download new data into Excel
There are some obvious downsides though:
  • There’s no easy way to pass parameters to the queries you use, and so allow the user to choose what data is retrieved from Power BI. I guess it would be possible with some VBA, though – I haven’t tried – and it may also be possible to connect Power Query/Get&Transform to the Power BI Service and then use some of the tricks I show in this video for building reporting solutions in Excel. You can of course use Excel’s own native table filtering functionality to filter the data that is downloaded.
  • If your DAX query is slow to run your users may get frustrated. To counter this you could create calculated tables in your Power BI dataset using the same DAX as your query, and because calculated tables are created when the Power BI dataset is refreshed rather than when your user refreshes their Excel worksheet this should speed things up. However it will increase the size of your Power BI dataset and make your dataset refresh take longer. In Excel your DAX query would simply be something like:
    EVALUATE ‘My Calculated Table Name’
  • Writing DAX can be complex, whether it’s a DAX query or a calculated table, so another option would be to use the Power BI Query Editor to create the table you need for your report, load that into your dataset and then load the table into Excel.
  • You can’t publish the Excel workbook up to Power BI and have it refresh automatically, because of course Power BI does not support connections from published Excel workbooks back to Power BI datasets. Hopefully this will change in the future – it marked as planned on the Ideas forum.

Comments

Popular posts from this blog

SharePoint Framework (SPFx).

What is SharePoint Framework   Client Side SharePoint Development using SharePoint Framework (SPFx). The SharePoint Framework (SPFx) development is a great milestone for SharePoint Client Side development. It is a page and web part model. This provides full support for client-side SharePoint development. It allows to easily integrate component with SharePoint data and supports for open source tooling. With SharePoint Framework, you can use any of your preferred web technologies and tools in your preferred development environment. It is to build responsive and mobile friendly SharePoint products and apps. SharePoint Framework (SPFx)   helps to build custom user interface extensions on top of SharePoint Online in supportive and future prepared way as SharePoint Online keeps itself updated time to time. Create new web part project You need to perform following steps:   1.       Create new project directory at your opted location md helloworld-webpart 2.   

Plan SharePoint Migration

Guide to a SharePoint Migration This blog will show how enterprises can approach their SharePoint migration with a few tried and tested action plans. This blog also details how you can successfully define a migration  roadmap, strategy, and goals for a successful SharePoint migration. There are four big transitions you’ll have to consider, before you dive into how to set up a pre-migration strategy. The Different Paths to Modern Management The following explains the four transitions and migrations that can be executed—successful or not. Cloud-first The Cloud-first path is perfect for startups, as there is no need for a migration. Essentially, everything is created in the cloud. Think: Cloud first and only cloud. Big Switch Transition The Big Switch path is often considered the most risky strategy, as organizations can never verify if the transition (also known as “big bang transition”) will end up as a success or a failure. Group by Group Transition

3 ways to filter SharePoint lists and libraries

One of the greatest benefits of metadata is the ability to filter on it and get to what you want with just a few clicks. Filtering for information is quite a common exercise these days. Every time we do online shopping, we filter for stuff. When we shop on Amazon® for shoes (something I do every day 🙂 ), we filter on cost, shoe size, reviews, brand among other things. When you go to a bookstore website, you filter for author and genre. When you research your dream car – you filter on car type, fuel economy, color. In SharePoint, we have not one, but three ways to filter SharePoint metadata! Today I would like to describe and explain all the three options to you. Option 1: Column header filter This is the most basic option that has been available ever since custom columns became available in SharePoint. Essentially this is the filtering you do using column headers. The functionality might be well familiar to many users as this is something we can do in Excel as well.