So rather than fighting Excel, let’s look at the options Microsoft provides for bringing governed Power BI data into it. In particular, I’m interested in getting data from Fabric semantic models into Excel.

Many things have changed over the years in the data analytics space, but semantic models have stood the test of time. The technology has changed—from multidimensional OLAP cubes to tabular models and now Power BI and Fabric semantic models—but the basic idea has remained remarkably consistent: put business logic and governed data in a centralized model, then let different tools consume it.

Here are the main options Microsoft provides today to make data from semantic models available in Excel:

Export from published reports

This is probably the most obvious option. A Power BI or paginated report can serve as the interface for users, with Excel being the ultimate destination. This approach can be particularly attractive when the organization wants to take advantage of everything Power BI has to offer: report sharing, subscriptions, dynamic subscriptions, annotations, and other collaboration features.

For example, a report can be designed specifically for a group of users and distributed through a subscription. Paginated reports provide even more flexibility when the objective is to produce formatted Excel or CSV files on a recurring basis.

The problem is that Power BI report exports have limitations. Depending on the report and export method, there are limits on the amount of data that can be exported. Paginated reports are considerably more flexible for large-scale tabular output. There is also an architectural question: do we really want to build a Power BI report whose primary purpose is to get data into Excel? If the report exists only because Excel is the final destination, we’re arguably using the report layer as an unnecessary intermediary.

The better architecture is often: Semantic model → Excel rather than: Semantic model → Power BI report → Excel

Excel PivotTables and PivotCharts

Excel has supported PivotTables since the 1990s and OLAP PivotTables for more than 25 years. This is hardly new technology. And that’s part of the appeal. The experience is familiar to generations of Excel users. A user can connect to a Power BI semantic model, select fields, slice and dice the data, and create PivotTables and PivotCharts without building a Power BI report.

The problem is that the fundamental PivotTable interaction model has changed surprisingly little. Slicers and timelines improved the experience, but the overall model still feels much closer to the Excel/OLAP world of the early 2000s than to today’s Power BI experience. As such, it generates suboptimal MDX queries although not as bad as Power Query in import mode.

For an Excel user, however, there is one particularly interesting capability: customizable drillthrough. When a user double-clicks a PivotTable cell, the semantic model can provide a detailed table of the underlying records. A semantic-model developer can control this behavior using the measure’s Detail Rows Expression, which can return a table-producing DAX expression. This is a powerful capability when the semantic model has been designed with Excel users in mind.

There is a catch, though. If you are developing a semantic model that must support both Power BI and Excel users, you need to design for the least common denominator. Excel’s live-connection experience does not expose all the capabilities available in Power BI reports. For example, there are differences around field parameters, some filtering scenarios, custom visuals, and metadata behavior. Even seemingly small modeling decisions can affect how the semantic model appears in the Excel Field List.

In other words, a semantic model that works beautifully in Power BI isn’t necessarily going to provide the same experience in Excel.

Power BI connected tables

This is the option that could have the most potential if it wasn’t another half-baked Excel reporting feature. Microsoft introduced connected tables in 2023, but the experience has evolved considerably since then. Excel can now discover Power BI semantic models directly, and users can choose to insert either a PivotTable or a Table from the semantic model.

The Table option is particularly important because it delivers the data in the format most business users actually want: an Excel table. The user can select the fields they need and apply filters through a dedicated interface, rather than having to write DAX or build a Power BI report first. This is a significant improvement over the traditional export experience.

For years, the missing piece in the Microsoft BI stack was obvious: Excel users wanted the flexibility of a PivotTable’s field-selection interface but wanted the result as a regular Excel table. Connected Tables finally moves in that direction. It is also a much better architectural model: Fabric semantic model → Excel table. There is no Power BI report in the middle.

On the downside, the user interface is lost once data is exported. Consequently, the user must change the underlying DAX query (a client immediately dismissed this option after learning about this) if they want to make changes, such as adding additional fields. This could be a great option if there is a way to bring back that interface. Even better, let the user pick fields from Field List as they can with pivots but export to a table. What could be simpler?

Power Query

Another option is hiding in Excel’s Get Data experience. Power Query can connect to Power BI semantic models and provides considerably more flexibility than a simple connected table. Once the data is retrieved, users can transform it and even mash it up with other sources. For example, a user could combine:

Power BI semantic model + Excel file + another data source → Power Query → Excel table

It also makes Power Query a compelling option when the requirement isn’t simply “show me this data,” but rather: “Get this data, transform it in these ways, combine it with my other data, and give me a reusable result.”

The biggest issue we faced with this option was performance. For reason unknown, in import mode the Analysis Services connector generates horrible MDX queries, with nested CROSSJOINs, one for each imported field.  This was another showstopper for us. In addition, Power Query is a data-transformation tool, not a simple business-user reporting interface. Users must understand queries, transformations, refresh, data sources, and credentials. Excel’s Power Query implementation also doesn’t expose every connector and capability available elsewhere in the Microsoft data platform.

So, while Power Query is powerful, it isn’t necessarily the best answer for a business user who simply wants to select a few fields from a semantic model.

Excel Copilot

And, of course, there is AI. I’ve personally found Excel Copilot very useful for tasks such as generating test data, transforming data, and working with existing spreadsheets. Microsoft is now taking this a step further by integrating Power BI data into Copilot in Excel. The new Power BI grounding capability allows Copilot to use governed Power BI data when answering requests in Excel. This is potentially a very different way of interacting with a semantic model.

Instead of teaching a user how to navigate a Field List, write DAX, or configure a Power Query, the user can simply say what they want.

For example: “Bring me revenue, margin, and customer name for the current fiscal year. Filter to the Southeast region and sort by revenue descending.”

That’s exactly the type of task for which natural language makes sense. The technology is still rough around the edges, though. The experience can be slow, and the interaction isn’t yet ideal for creating a reusable library of data-extraction definitions. A prompt that works for one user isn’t necessarily a well-defined, portable query definition that another user can reuse with predictable results.

For Copilot to become a serious enterprise data-extraction mechanism, I’d like to see prompts evolve into something more like shareable, governed query definitions—something a business analyst can create once and distribute to other users.

Unfortunately, what’s missing is the Field List. To make the feature useful, the user should be able to access the Field List and remove, add, filter, as they can do with pivots. However, once the table is generated, to change it you either must go through the wizard again or change the DAX query (right-click the table, click Table, and then Edit Query). Down the DAX rabbit hole we go again…

As they stand, Excel connected tables are not an interactive browsing tool. Instead, they are geared towards making Power BI datasets accessible in Excel.

Since I lost hope that Excel will discover Tabular and DAX one day, I hope the community will step in to fill in the gap by providing UI like the Pivot Field List so that the user doesn’t need to mess with DAX when all that’s needed is an Excel connected table for ad-hoc data exploration.

For some reason, this feature is called “connected PivotTable refresh” although a better name would be “interactive Excel pivots finally”. It works in Power BI Pro and Premium. Unlike the initial announcement that speculated that this feature would be available by simply uploading your Excel file to Power BI Service, it appears that it requires the Excel file to be uploaded to OneDrive or SharePoint Online. Here are the high-level steps that worked for me:

1. Create your Excel pivot using the Analyze in Excel feature or directly from Excel. Assuming you have a recent Office 365 build, the latter option allows you to open Excel on the desktop and click Insert->Pivot Table->From Power BI to connect to a Power BI dataset from within Excel Desktop.
2. Click Save As and save your workbook to OneDrive or SharePoint Online. Recall that you can specify a SharePoint site for storing workspace files in the Power BI workspace settings if you don’t want to upload the file to your personal folder.
3. Use the Power BI Service “Get data” feature to upload (not import) the Excel workbook in a Power BI workspace. Again, the Excel workbook must be located either in OneDrive or SharePoint online.
4. Interact with the report in Power BI Service, such by drilling down, drilling through, or even rebinding the report to different fields! As a bonus, when the underlying dataset refreshes, your pivot report will show the latest data as it connects live to the dataset.

The “connected PivotTable refresh” is a much-needed enhancement that brings the same interactive features to Excel pivot reports that users previously had in SharePoint Server. Now users who favor Excel pivots for interactive exploration can share their reports and the interactive features would be preserved when the report is rendered online. The feature requires storing the Excel workbook in OneDrive or SharePoint Online and using an Analyze in Excel connection. Unfortunately, it doesn’t work with Analysis Services models that are external to Power BI (not deployed to Power BI Service) which is another incentive to move your semantic models to Power BI as I’ve been advocating for some time.

Workaround: Currently, there is no way to default a field in Tabular and Power BI. For the most common requirement to default a date filter, consider adding a field to the Date table that flags the desired item. You can implement this in different ways. For example, in Excel you can create a named set, but this requires MDX knowledge that end users won’t have. And it won’t work in other report clients, such as Power BI Desktop. Here is an approach that is simple to implement and works everywhere.

1. Flag the desired item using whatever way you’re comfortable with: SQL view, Power Query, or DAX. For example, if users prefer the date filter to default to yesterday and the Date table is based on a SQL view, add the following column to the view:
   CASE WHEN [Date] <= DATEADD(DAY,-1, CAST(GETDATE() AS DATE)) THEN ‘Yes’ ELSE ‘No’ END YesterdayFlag
   Notice that the flag qualifies all rows prior to and including yesterday. In your first attempt, you might try only an equal condition. This will work when the YesterdayFlag field is added as a filter to an Excel pivot table. However, if you attempt to configure it as an Excel slicer, it will result in the following error:
   Calculation error in measure ‘<your measure name>’: Function ‘SAMEPERIODLASTYEAR’ only works with contiguous date selections.
2. Reimport the Date table in Tabular or Power BI.
3. Set up a report filter. For example, in Excel define a slicer using the YesterdayFlag field and default it to Yes, if you want to filter all reports on the same sheet.
   

   The net effect is that as time progresses, the YesterdayFlag field will filter the Date table and measures will show the yesterday’s data by default. Time calculations will also work as of yesterday. For example, YTD calculations will aggregate from the beginning of the year until yesterday. And end users don’t need to bother about resetting date filters if viewing data as yesterday is the prevailing preference.

According to Microsoft, a better Excel-Tabular combo hasn’t yet bubbled up high based on the feedback that the Excel team gets from customers. In an attempt to get the proper attention, I just posted the “Better Support for Analysis Services Tabular” wish list on Excel User Voice. I bundled multiple items into one wish list.

Please vote if you care.

It’s about time to improve support for SSAS Tabular:

1. Auto-generate DAX.

2. Avoid splitting a table into a “measure group” and “dimension”. See how PBI Desktop handles metadata.

3. Carry over data types so that users can create reports, such as show me invoices where Due Date is greater than … Currently, all dimension table fields map to Text.

4. Many customers have expressed interest in connecting Excel tables directly to Tabular, bypassing Pivot Table, so they can use the column dropdowns and other Excel Table goodness.

5. Support descriptions as tooltips when the user hovers on a field in the Field List.

Multidimensional is an attribute-based model and the server cross joins the member values when you add attributes to the report. Don’t be misled by the “relational” nature of Tabular either. Its database engine (xVelocity) is an in-memory columnar database that still cross joins the column values. That said, Tabular should give you a performance boost for two reasons. First, its in-memory nature is generally faster than Multidimensional. Second, Excel has been optimized for Tabular, as I explain in my “Optimizing Distinct Count Excel Reports” blog, thanks to the undocumented PreferredQueryPatterns settings (although not listed in the msmdsrv.ini, it defaults to 1).

In a recent project, I migrated a customer from Multidimensional to Tabular. Besides other benefits, such of elimination of snapshots, reducing dramatically ETL time and analyzing data as of any date (not just at the month end), the customer wanted to improve performance of Excel detail reports. Previously, some of the detail reports would never return. After the migration, these reports would execute within a minute, and in seconds if the Excel subtotals are disabled.

Here are some tips you might find useful if you’re tasked to produce detail reports:

1. If the detail reports don’t require too much interactivity, consider implementing them as SSRS paginated reports that connect directly to the database. The chances are that this approach will give you the fastest performance as the Database Engine is designed to retrieve data in sets by rows and the number of columns won’t probably affect report performance (unless of course many joins are required).
2. If it’s desired to connect these reports to a semantic layer, consider Tabular because it’s better for wide & flat results.
3. If Excel is used as a front end, consider Excel 2016 as Microsoft has made various performance improvements for detail reports.
4. Consider disabling Excel subtotals, as explained here. In my scenario, a detail report with no subtotals would execute under 15 seconds. However, if I enable just one column subtotal, Excel switches to a completely different query pattern (with many nested DrilldownMember levels) and the report query would take a minute. That’s because now the query needs to obtain the subtotals for each group from SSAS. Since we’re at the mercy of the Excel MDX query generator, I hope the Excel team finds a way to produce more optimal MDX queries. Ideally, a future Excel release would allow binding Excel native tables directly to SSAS with ability to define subtotals and optimized queries to load the data.
5. In my experience, Power BI reports that generate DAX don’t perform necessarily any better. To make things worse, while the new PBI Matrix visual can be configured to a flattened layout, it doesn’t currently support disabling specific subtotals (currently, you can remove all row subtotals or have them for each and every column). And asking for subtotals for every column might not only contradict business requirements but it could also severely affect performance. UPDATE 8/14/2017 – The August release of Power BI Desktop supports configuring row subtotals per level.

Many thanks to Akshai Mirchandani for the SSAS product group for not losing patience throughout all these years from my complaints on this subject.

Power BI is gaining a momentum but Excel still rules the corporate world. Fortunately, Power BI and Excel are not exclusive choices. Join me to learn how you can preserve your Excel investment in Power BI. I’ll start by explaining the value Power BI brings to different types of users in your organization. Then, I’ll discuss and demo seven options for integrating Excel with Power BI:

• Import Excel files in Power BI Service
• Build self-service data models from Excel data
• Deploy Excel models to Power BI
• Convert Excel models to Power BI
• Connect to Excel reports
• Analyze Power BI datasets in Excel
• Add Excel reports to Power BI dashboards

I’ve noticed that Microsoft added not yet documented PublishToPBI method to Excel 2016. With it, refreshing the Excel data model and publishing it to Power BI Service takes two lines of code (you’d need more code to open the Excel workbook from an external application).

Sub Macro1()

ActiveWorkbook.Model.Refresh

ActiveWorkbook.PublishToPBI PublishType:=msoPBIExport, nameConflict:= msoPBIAbort, bstrGroupName:=”<Some Workspace>”

End Sub