Evaluation of Power BI November 2018 Release
The following is part of an ongoing series on Power BI from Shawn Alpay. Shawn is a Business Intelligence Architect at Senturus who has spent the last 15 years designing and implementing Microsoft-centric BI solutions for clients.
Shawn Alpay here again, bringing you a rundown of the new features in Power BI for November 2018. We have two sets of features to dig into today: those released with Power BI Desktop and those released with the Power BI service: paginated reports and dataflows.
This is a huge month for Power BI, so we have a lot to cover! As always, I’ll only be digging into features that elicit my strong opinion and/or really move the needle in the long arc of Power BI’s maturity curve – so I won’t be covering stuff like custom visuals and Q&A. (I have a bias and I’m not afraid to use it!) Let's get started.
New relationships experience
Even with all the new features, it wasn't hard for me to choose where to start: the new modeling experience in Power BI Desktop. It's a preview feature, so you have to enable it in the Options menu. Once you do, you get a new Relationships pane that is just chock full of new features:
- A Properties pane over on the right! No more having to right-click a field to hide or rename.
- Display folders! This sounds simple, but it's honestly my single favorite feature released this month. I think a model lives and dies by its ability to organize the information presented to users — and any model worth its salt probably carries enough attributes and measures to justify grouping them together into one or more levels of folders. We've been able to do this in Analysis Services for many years, so the ability to do this in Power BI semantic models has been extremely sorely needed.
- The ability to multi-select fields! This is so critical for hiding (or assigning display folders to) multiple fields at once.
- Performance improvement! The old Relationships pane really bogged down with larger models. By "larger" I mean "more than 10 tables," which really isn't that large at all. The new Relationships pane is really snappy.
- Multiple layouts! We've only ever been able to see the entire model at once, and now we can look at subsections of the model. This can be used to present each star schema (aka each fact with its related dimensions) separately, which is super useful for all sorts of reasons, including documentation and maintenance.
Please, pardon my enthusiasm! But this new experience was a long time coming, and I'm already making good use of it in the trenches.
Get ready for some really big news: we can now present paginated reports (aka Reporting Services reports, aka RDLs) in the Power BI service! (For more details, see the announcement.)
This ability will allow us to completely sidestep installing and using Reporting Services. I think that's a big deal. addressing a big missing piece when considering Power BI to be a one-stop-shop for all presentation layer artifacts in the Microsoft ecosystem. Up until now, it's been an awkward dialogue with clients to explain how enterprise reporting and self-service reporting have to be published to two different places in the Microsoft BI stack.
That said, this is very much a v1 feature, and it's a case where I really do wish Microsoft had waited a bit longer before shipping, because there are so many limitations that it's hardly something I can justify implementing for my clients in its current form. To wit
- We can only use SQL Server or Analysis Services as data sources. The fact that we can't yet use a Power BI dataset is a HUGE miss. I'm SURE it's coming, but this alone is a deal breaker for my clients who don't have SQL Server or SSAS (yes, Microsoft, those clients exist!).
- We can't publish from SQL Server Data Tools or Report Builder. You have to awkwardly save that RDL somewhere locally, then upload it via the Power BI service. I understand that SSDT and Report Builder are maintained by separate product teams at Microsoft, but I would have expected going to market with some semblance of coordination between those teams.
- We can't publish paginated reports to an app, they can only be accessed in an app workspace. This doesn't make any sense: I'd only ever want to present a paginated report to someone who's purely a report consumer, and therefore, I'd only want to present this to users with a Power BI free license in an app with Premium capacity. Which brings me to my biggest criticism…
- We can only use paginated reports in Premium capacities. To me, this is a travesty and the latest in a long tradition of Microsoft trying to upsell organizations on more expensive SKUs.
You might recall when Microsoft eventually added many Enterprise Edition features of SQL Server to the Standard Edition, given that putting the product's more advanced features out of reach of many users resulted in a lower overall SQL Server adoption rate than they would have liked (go fig). Microsoft is betting that people will want paginated reports badly enough to pony up for Premium, but mark my words: they will walk this one back, eventually. It might take a year or two, but I guarantee you that paginated reports will someday not be exclusive to Premium capacities.
To be clear: I'm VERY excited about this new feature. It's great that it was added, and I'm sure it will eventually see heavy use. It's just not what I was expecting and I hope that that changes over time. We'll see.
Since the inception of Power Query alongside Power Pivot in Excel several years ago, we've been able to prepare our data via a really nice user interface before we import it into our semantic model. That interface has only grown better over time. Starting this month, we can now perform our transformation work in the Power BI service and save it as a new object called a dataflow. (For more details, see the announcement.)
Microsoft says "with dataflows, ETL logic is elevated to a first-class artifact." I really like the way they've put that; data prep really has been a second-class citizen in the Power BI ecosystem, living subservient to the semantic model. The analogy would be like if Integration Services only existed as a component of Analysis Services, which obviously doesn't make sense, as SSIS offers many destinations beyond SSAS.
It's intriguing to me that the dataflow object is essentially an implementation of what Microsoft's been calling the Common Data Model: a framework which assumes that every entity in a data model falls into a predefined type, like Account, Organization, Invoice, Order, Event, and so on. A dataflow encourages you to apply a particular entity type to every entity you add; Microsoft argues that this promotes "structural and semantic consistency across applications and deployments," and it's hard to argue with that.
We can create one dataflow per data source, and then we can link them together, so analysts can reuse data without duplication and build off of each other's work, both inside and outside Power BI. It's an excellent concept, and it's really what will take adoption of Power BI to the next level across larger organizations.
So the proposed order of operations in this new ecosystem is now dataflow –> dataset –> report. But disappointingly, we can't "live connect" from a dataset to a dataflow the same way that we can "live connect" from a report to a dataset. When I first heard about dataflows, I had hoped that I could keep my data in the dataflow and my semantic model in the dataset, but this currently isn't possible. The dataset needs to load data from the dataflow, thereby creating a copy of information that I personally perceive to be unnecessary. I'm hopeful that avoiding this reload will become a possibility in a future release.
I haven't yet dug deep into dataflows, so I'll be sure to check back in with you once I've had a chance to really get my hands dirty.
Expand/Collapse in matrix visual
This brings a PivotTable-esque experience to the matrix visual: now, a user can click the + and – buttons to respectively expand and collapse a given hierarchy member. This addition is critical: the matrix visual is easily the best way to present detailed data, but until now we were forced to present a static view of the hierarchy. Now, you can browse information as you see fit, no longer needing to jump to Analyze in Excel to do so.
Copy and paste between Power BI Desktop files
We're now able to hit Ctrl-C on a visual in one PBIX, then hit Ctrl-V in a second PBIX. This functionality has consistently been one of the most-requested additions to Power BI (nearly 3,800 upvotes!!) – but to be perfectly honest, I don't get it.
Let's think about the use case: as a developer, I have a particular bar chart that I need to conveniently carry and maintain in two separate places. Why am I doing this?? I feel like I should only present a particular visual in ONE place, not TWO. So to me, this smacks of bad design. I cannot tell you the number of times I've seen 45 reports in a production environment that could easily have been two or three, because each report is a very small variation on a central theme, and no one on the design team was brave enough to recommend altering production reports to accommodate the incremental additions that a BI solution must inevitably support.
Therefore, as I recently said regarding the addition of PDF as a data source, I feel like this feature will merely enable bad behavior. I can see some situations where I might want to grab a slicer quickly from somewhere, but given that it takes literally eight seconds to build one from scratch, I don't really feel like I'm being saved any time with this functionality.
New filter experience
Users are often not sure how a particular visual, page or report is currently being filtered and Microsoft rightly wants to clear this up. So we now have a new pane dedicated solely to filters, rather than carrying them at the bottom of the Fields pane.
This pane is available to users (or not, depending on the designer's preference), and there are a bunch of other options here, like hiding certain filters from report consumers. This makes good sense, but there's a lot further to go. Currently, as developers, we can only see the filter composition in the new pane, and we still have to maintain them in the old pane. This will change in "a few months" once people get used to the new experience.
I suppose there's no good way to move the community's cheese, but I think I would have preferred Microsoft ripping off the Band-Aid and forcing us to cut over to the new experience. Then again, Microsoft is branding this as a "preview" feature, which seems like a term they use to give themselves cover for releasing features that don't yet seem ready for prime-time. As I previously described, I see this as a marketing choice, and I feel conflicted about it. But ultimately, I'd prefer to see where the product is going over waiting for a fully fleshed-out feature.
As an aside, I think this new pane confuses when to use slicers versus when to use the new Filters pane, as that functionality now overlaps. For now, I recommend sticking with slicers, as the Filters pane still feels clunky, but I fully expect it to change over time.
ISINSCOPE DAX function
It's always exciting news when we get a new DAX function! This month, we get a few new ones, but the most useful one is ISINSCOPE, which allows us to more easily deduce whether a given hierarchy level is currently in the given filter context. It's different than ISFILTERED, which we previously had to use repeatedly in monster DAX calculations to get to the desired result. If you'd like to know more, check out this blog post, which provides a really good rundown of how best to use it.
The one bummer about new DAX measures is keeping track of when we can and can't use them. We can now use ISINSCOPE in Power BI and Azure Analysis Services – but it's not in SSAS 2017, and I expect that it won't be added to SSAS until the next version (whenever that comes out). For that reason, it's hard to justify use of ISINSCOPE in a Power BI model that may at some point be ported to an on-prem instance of Analysis Services. One of my clients may soon do this, so I will most likely avoid using this function in their solution.
That's it for now! Come back next month and I'll have another rundown for you for the December 2018 release. There's not much on the feature roadmap that's slated for next month, but each release tends to contain at least one surprise, so we'll just have to see!
If you’d like to hear more from Shawn and learn more about Microsoft Power BI, check out his webinar Power BI: Beyond the Buzz. Shawn explains how the product fits into Microsoft’s overall business intelligence framework, reviews what it does well (and does poorly) and demos some of its more prominent features. Or read his workaround tip for printing reports in Power BI. You can also scroll through our blog page to find previous updates from Shawn on Power BI.