Power BI dataflows PowerShell scripts on GitHub

Last week I shared a post highlighting a common pattern for making API data available through dataflows in Power BI, and included a few diagrams to show how a customer was implementing this pattern.

In the post I mentioned that I was simplifying things a bunch to only focus on the core pattern. One of the things I didn’t mention is that the diagrams I shared were just one piece of the puzzle. Another part was the need to define dataflows in one workspace, and then use those as a template for creating other dataflows in bulk.

This is simple enough to do via the Power BI portal for an individual dataflow, but if you need to do it for every dataflow in a workspace, you might need a little more power – PowerShell, to be specific.

The rest of this post is not from me – it’s from the dataflows engineering team. it describes a set of PowerShell scripts they’ve published on GitHub, and which address this specific problem. The rest is pretty self-explanatory, so I’ll just mention that these are unsupported scripts presented as-is, and I’ll let the rest speak for itself.

nautilus-1029360_1920

Microsoft Power BI dataflows samples

The document below describes the various PowerShell scripts available for Power BI dataflows. These rely on the Power BI public REST APIs and the Power BI PowerShell modules.

Power BI Dataflow PowerShell scripts

Below is a table of the various Power BI PowerShell modules found in this repository.

Description Module Name Download
Export all dataflows from a workspace ExportWorkspace.ps1 GitHub Location
Imports all dataflows into a workspace ImportWorkspace.ps1 GitHub Location
Imports a single dataflow ImportModel.ps1 GitHub Location

For more information on Powershell support for Power BI, please visit powerbi-powershell on GitHub

Supported environments and PowerShell versions

  • Windows PowerShell v3.0 and up with .NET 4.7.1 or above.
  • PowerShell Core (v6) and up on any OS platform supported by PowerShell Core.

Installation

  1. The scripts depend on the MicrosoftPowerBIMgmt module which can be installed as follows:
Install-Module -Name MicrosoftPowerBIMgmt

If you have an earlier version, you can update to the latest version by running:

Update-Module -Name MicrosoftPowerBIMgmt
  1. Download all the scripts from the GitHub Location into a local folder.
  2. Unblock the script by right click on the files and select “Unblock” after you download. Otherwise you might get a warning when you run the script.

Uninstall

If you want to uninstall all the Power BI PowerShell cmdlets, run the following in an elevated PowerShell session:

Get-Module MicrosoftPowerBIMgmt* -ListAvailable | Uninstall-Module -Force

Usage

The APIs below supports two optional parameters:

  • -Environment: A flag to indicate specific Power BI environments to log in to (Public, Germany, USGov, China, USGovHigh, USGovMil). Default is Public
  • -V: A flag to indicate whether to produce verbose output. Default is false.

Export workspace

Exports all the dataflow model.json from a Power BI workspace into a folder:

.\ExportWorkspace.ps1 -Workspace "Workspace1" -Location C:\dataflows

Import workspace

Imports all the dataflow model.json from a folder into a Power BI workspace. This script also fixes the reference models to point to the right dataflow in the current workspace:

.\ImportWorkspace.ps1 -Workspace "Workspace1" -Location C:\dataflows -Overwrite

Import dataflow

Imports a dataflow model.json into a Power BI workspace:

.\ImportModel.ps1 -Workspace "Workspace1" -File C:\MyModel.json -Overwrite

Data Culture: Picking Your Battles

Not all data is created equal.

One size does not fit all.

In addition to collaboration and partnership between business and IT, successful data cultures have something  else in common: they recognize the need for both discipline and flexibility, and have clear, consistent criteria and responsibilities that let all stakeholders know what controls apply to what data and applications.

2020-08-01-19-55-59-794--POWERPNT

Today’s video looks at this key fact, and emphasizes this important point: you need to pick your battles[1].

If you try to lock everything down and manage all data and applications rigorously, business users who need more agility will not be able to do their jobs – or more likely they will simply work around your controls. This approach puts you back into the bad old days before there were robust and flexible self-service BI tools – you don’t want this.

If you try to let every user do whatever they want with any data, you’ll quickly find yourself in the “wild west” days – you don’t want that either.

Instead, work with your executive sponsor and key stakeholders from business and IT to understand what requires discipline and control, and what supports flexibility and agility.

One approach will never work for all data – don’t try to make it fit.


[1] The original title of this post and video was “discipline and flexibility” but when the phrase “pick your battles” came out unscripted[2] as I was recording the video, I realized that no other title would be so on-brand for me. And here we are.

[2] In case you were wondering, it’s all unscripted. Every time I edit and watch a recording, I’m surprised. True story.

Dataflows and API data sources

These days more and more data lives behind an API, rather than in a more traditional data source like databases or files. These APIs are often designed and optimized for small, chatty[1] interactions that don’t lend themselves well to use as a source for business intelligence.

beehive-337695_1280
I’d explain the choice of image for APIs, but it doesn’t take a genus to figure it out

These APIs are often slower[3] than a database, which can increase load/refresh times. Sometimes the load time is so great that a refresh may not fit within the minimum window based on an application’s functional requirements.

These APIs may also be throttled. SaaS application vendors often have a billing model that doesn’t directly support frequent bulk operations, so to avoid customer behaviors that affect their COGS and their bottom line, their APIs may be limited to a certain number of calls[4] for a given period.

The bottom line is that when you’re using APIs as a data source in Power BI, you need to take the APIs’ limitations into consideration, and often dataflows can help deliver a solution that accommodates those limitations while delivering the functionality your application needs.

I’ve covered some of the fundamental concepts of this approach in past blog posts , specifically this one from 2018 on Power BI Dataflows and Slow Data Sources, and this one from 2019 on Creating “data workspaces” for dataflows and shared datasets.  I hadn’t planned on having a dedicated new blog post, but after having this pattern come up in 4 or 5 different contexts in the past week or so, I thought maybe a post was warranted.

In late July I met with a customer to discuss their Power BI dataflows architecture. They showed me a “before” picture that looked something like this:

2020-08-01-13-40-14-887--POWERPNT

One of their core data sources was the API for a commercial software application. Almost every Power BI application used some data from this API, because the application supports almost every part of their business. This introduced a bunch of familiar challenges:

  • Training requirements and a steeper-then-necessary learning curve for SSBI authors due to the complex and unintuitive API design
  • Long refresh times for large data extracts
  • Complex, redundant queries in many applications
  • Technical debt and maintenance due to the duplicate logic

Then they showed me an “after” picture that looked something like this:

2020-08-01-13-40-32-810--POWERPNT

They had implemented a set of dataflows in a dedicated workspace. These dataflows have entities that pull data from the source APIs, and make them available for consumption by IT and business Power BI authors. All data transformation logic is implemented exactly once, and each author can easily connect to trusted tabular data without needing to worry about technical details like connection strings, API parameters, authentication, or paging. The dataflows are organized by the functional areas represented in the data, mapping roughly to the APIs in the source system as viewed through the lens of their audience.

The diagram above simplifies things a bit. For their actual implementation they used linked and computed entities to stage, prepare, and present the dataflows, but for the general pattern the diagram above is probably the right level of abstraction. Each IT-developed or business-developed application uses the subset of the dataflows that it needs, and the owners of the dataflows keep them up to date and current.

Life is good[5].


[1]There’s a lot of information available online covering chatty and chunky patterns in API design, so if you’re not sure what I’m talking about here, you might want to poke around and take a peek[2] at what’s out there.

[2] Please let me know if you found the joke in footnote[1].

[3] Possibly by multiple orders of magnitude.

[4] Or a given data volume, etc. There are probably as many variations in licensing as there are SaaS vendors with APIs.

[5] If you’re wondering about the beehive image and the obtuse joke it represents, the genus for honey bees is “apis.” I get all of my stock photography from the wonderful web site Pixabay. I will typically search on a random term related to my blog post to find a thumbnail image, and when the context is completely different like it was today I will pick one that I like. For this post I searched on “API” and got a page full of bees, which sounds like something Bob Ross would do…

Data Culture: Roles and Responsibilities

In last week’s post and video we looked at how business intelligence tools have evolved, with each evolution solving one set of problems and introducing another set. The video described how self-service BI tools have enabled business users to work with data in ways that used to require specialized technical skills, freeing up IT to focus on other tasks – but at the same time introducing challenges around oversight, consistency, and control.

And that brings us to today’s video.

The video includes a few different graphics, but for this post I want to highlight this one, which I’ve taken from the Power BI Adoption Framework[1].

2020-07-31-20-44-46-355--POWERPNT

Successful cultures balance freedom and restriction in ways that benefit the culture as a whole. It’s a compromise – no one gets everything they want, but everyone gets the things they need the most.

For a data culture, this typically involves letting IT do the things they do best, and letting business get down to business.

When an organization adopts a managed self-service model for business intelligence[2], the central BI team in IT[3] does the heavy lifting. This means they prepare, cleanse, warehouse, and deliver the biggest and most important[4] data. They deliver the data that would be hard for a business user to create using a self-service tool, and which will be used by a large audience. They do the things that have broad reach, strategic impact, and strategic importance. They create things that need to be correct, consistent, and supported.

And business users do the rest. This is a broad bucket, but it’s a reasonable generalization as well. Business users create their own reports using the IT-managed data sources and data models. And they prepare and use their own data where there is no IT-managed data for a given purpose.

Over time a given application or a given data source may become more or less managed, as the culture adopts, adapts, and improves.

Managed self-service BI isn’t the only way to be successful, but in my experience working with many large Power BI customers it’s the best way and most predictable way. By having clearly defined roles and responsibilities – who does what – moving from either extreme can overcome the problems that that extreme creates, without going too far in the other direction.

Does your organization take this approach?

If it doesn’t today, what will it take to make this change a reality?


[1] Which I have shamelessly stolen from the Power BI Adoption Framework, because it is an awesome graphic and because I love to stand on the shoulders of giants.

[2] Which is the approach most likely to drive short-and long term efficiencies and successes.

[3] Please understand that this is a gross simplification. This “central BI team in IT” may be a single central team for the whole company, it may be a single central team for a specific business unit, or it may be one of dozens of BI teams that are designed to support a distributed global enterprise. This is less about the technology and the culture than it is about organizational structure, so I don’t expect to ever try to tackle this diversity of approaches in this series.

[4] Next week’s video will talk a little more about what data is likely to qualify for this distinction. And since the video is done already, I’m pretty confident to say “next week” this week.

Weekend reading: New dataflows docs

In case you didn’t have any plans for the weekend, the Power Query team has released a treasure trove of new documentation for dataflows in Power BI and Power Apps.

You can find the new docs here: https://docs.microsoft.com/en-us/power-query/dataflows/overview-dataflows-across-power-platform-dynamics-365

There are over 20 articles in this new resource, and the content they contain answers many of the questions I hear most frequently. For some reason WordPress isn’t letting me upload the screen shot I took of the content outline, so instead here is a picture of me[1] when I first learned about this new content:

woman-591576_1280

Please check out this new information, and please submit feedback to the documentation team using the feedback form on each page. When you let the docs team know what you like, what you don’t like, or what is missing, they read every comment!


[1] Me in my avatar as a photogenic young woman.

5’ve got all the swords

Power BI turns five years old this week. On July 24, 2015 Microsoft announced the general availability of Power BI, a new cloud service for self-service business intelligence.

In the five years since then Power BI has evolved to be much more than a self-service tool. Power BI today includes capabilities for self-service and enterprise BI, adding data preparation, information management, machine learning and more, while still including powerful tools for data visualization and reporting.

Today[1] the Power BI team at Microsoft is commemorating this milestone by saying thank you.

PowerBI_5YearAnni_1584x396-04-1024x256

Even though I’m on the Power BI team at Microsoft, this is my personal blog, and I wanted to say thank you as well. So I put together a short video that includes five of my favorite things:

  1. Power BI
  2. Swords
  3. Bad jokes
  4. My awesome new “5’ve got the Power BI” t-shirt
  5. Worse jokes[2]

The one thing I couldn’t include is all of you.

Thanks for the comments and feedback on the blog and the videos, and thanks even more for helping make Power BI what it is today.

 


[1] Yes, I know today is July 23rd here in North America, but by commemorating this milestone today we can be more inclusive for folks in parts of the world where it’s already the weekend.

[2] There is one joke in the video that I suspect I am the only person who will understand enough to laugh at it. If you get it please tell me so I don’t feel so alone.

If you cannot change, you cannot grow

Back in 2013 I presented for the very first time at the MVP Global Summit. I was terrified.

At this point I had been working for Microsoft for five years. I’d been an MVP before joining Microsoft as an employee and I had been a regular public speaker for many years – but this presentation felt different. MVPs are some of the most technical, most vocal, and most skilled people I know, and as a general rule they are talented presenters and communicators. I was very nervous, and I wanted to break the ice, both to help myself relax and to set an open and conversational tone for the session.

So I started my presentation like this:

2020-07-01-15-36-56-716--POWERPNT

A warning before we proceed: This post is likely to have more coarse language than I usually use. If you’re offended by swearing you may want to consider skipping this one, but I hope you’ll read on. I’m writing the warning before I write any swears, so maybe I’ll find another approach by the time I get there.

As the initial icebreaker I used the cover of Madonna’s 1984 album “Like a Virgin.” This was my first MVP Summit presentation, and I wanted to remind everyone that even though I might be a familiar face, this was my first time… or close enough.

The next slide represented the transition from the intro into the technical content of the session. I wanted to emphasize how we were talking about internal Microsoft processes and planning[1], and that the session would share these details that are typically not shared with anyone not on the product team… so I used the title “opening the kimono[2]” and as a family-safe but slightly risqué visual joke I used a “no image found” placeholder for the slide body.

The session went better than I could have hoped. People laughed where I wanted them to laugh, and shared deep technical feedback and constructive criticism were I wanted them to share deep technical feedback and constructive criticism. I was very happy.

Until later in the day, when someone came up to me to let me know that there were complaints. That someone had been offended, that someone hadn’t liked my choice of slides and sexually charged metaphors and images.

I was shocked.

The MVP who was reporting the news let me know that he wasn’t at all offended, and that the complaint came from someone who was always complaining anyway. “You know who,” he said to me, knowingly. I didn’t know who, and I never tried to find out who[3].

Instead, I thought about how my actions had a negative impact on someone in a way I didn’t plan, intend, or desire, but which was real nonetheless. That process was painful, and even now – almost seven years later – it is still uncomfortable to write about. I’m worried that someone might comment “you should have known better, you were an adult and 2013 wasn’t 1984” because criticism is difficult, and maybe they were right. Maybe I should have known better, but I didn’t, and because I didn’t I caused problems for someone who didn’t need me causing problems for her.

And I didn’t do it again. I messed up, I learned about my error, and I did my best to correct it. I made a choice, and I chose to change and grow.

That was 2013. Now let’s fast-forward to 2020.

Last week one of my data platform community heroes, Jen Stirrup, stepped down as a Microsoft MVP because the MVP program has not chosen to change and grow.

I want to unpack that last sentence before I proceed. Please bear with me, because this is important.

Jen is one of my heroes. She’s deeply technical – she’s one of those people who knows more things about more things than anyone could ever be expected to know. She works with some of the biggest companies in the world, helping them deliver global scale data solutions using a huge range of technologies. She can hold her own standing with the best of the best because she’s that good. She’s also an effective communicator who freely and selflessly shares what she knows. She’s soft-spoken, but when she’s speaking it’s worth leaning in and listening to what she has to say.

But that’s not the only reason she’s a hero. Jen is compassionate and tireless, and speaks the hard truths where so many others would chose the easy path and remain silent. Jen consistently chooses the right thing even though she knows it is also the hard thing.

And Jen chose to give up her status as an MVP. If you know anything about the program, you’ll know that this is a big deal. The MVP program comes with significant benefits and access to information that is invaluable to someone in her profession. I remember being an MVP and I know that I could not have done what she did. I am in awe.

The final thing I want to unpack is community – I called Jen a data platform community hero. The context of a community carries some baggage that may not be obvious, and I want to look at it a little bit here. Every community is defined by the behaviors it tolerates. If a community tolerates abusive behavior, that abusive behavior will thrive and will become the norm. People who can’t tolerate the abusive behavior will leave, and they won’t return. People who are made uncomfortable by the abusive behavior will engage less, and contribute less. And people who appreciate the abusive behavior will recognize that it is allowed, and they will repeat and amplify it. This is how communities work – not just technical communities.

Weeding out the “bad apples” isn’t enough. Successful communities need to define what they want to be, and to do it deliberately. I don’t know of any technical communities that do this[4], but I know one in another part of my life: Valkyrie Western Martial Arts Assembly. Valkyrie is a martial arts school in Vancouver, BC that saw the abusive behavior in the North American HEMA[5] community and decided to be something different. In this awesome blog post, Valkyrie co-owner Kaja Sadowski describes how she did what she did, and why. Please read the whole post (it’s much shorter than this one) but for now, please read this bit:

If a female student is worried about whether the guy she’s partnered with is going to hit on her again, or “accidentally” grab her breast, or refuse to hit her in drills, she can’t focus on her training. If an Asian student feels like he has to prove he’s not a bookish stereotype, or has to put up with constant shitty Kung Fu jokes, he can’t focus on his training. If a queer student is anxious about how their fellow students will react when their partner comes to pick them up after class, or a transgender student is stuck worrying they’ll be called out for using the “wrong” bathroom or misgendered by their training partner, they can’t focus on their training. All of these students end up in a position where their learning suffers, because they can’t put 100% of their energy and effort into their training and instead have to deal with the background noise of harassment and discrimination. If I put them in that position, I have failed them as an instructor.

Kaja decided that inclusion and diversity was important, so she decided to be aggressively inclusive.

Aggressively. Inclusive.

And the results are fantastic. I’m a middle-aged straight white guy. I’m tall and reasonably fit and reasonably good and I expect I would be welcome in any club. I have never felt more welcome than I am at Valkyrie. I visit Valkyrie for events, and am delighted when they come down to my club in Seattle for our events. They built a community that is aggressively inclusive for the people who might feel unwelcome in a traditional martial arts school, and along the way they built a community that includes everyone.

That’s how inclusion works.[6]

I’m not done. There’s one more thing I need to call out here – both because it’s important and because it is central to Jen’s decision – and that is the #MeToo movement.

Some of you might be saying “MeToo is so 2017, is that still a thing?” I hope not, because that is likely to get the swearing started, and I’ve done so well so far.

MeToo has the name that it does because women have put up with sexual harassment and sexual abuse that men don’t experience, and often men don’t see. Women are literally saying “me too – I have also suffered the thing that you are talking about” because for far too long they’ve been told everything but this.  Most[7] of the women you work with have been harassed and abused at every step of their careers, and they’ve tolerated it as best they could.

This is important, and this goes back to my personal story from 2013.

My choice of slides may not have been a big deal. On their own, they may not have been worth mentioning, even for someone who would rather I chose different images and phrases. But they weren’t on their own – they were part of a lifetime of challenges and indignities large and small. Despite my lack of malice, they were another straw on the back of someone who didn’t need one more person telling her she wasn’t welcome, and I was that person. Casual sexism doesn’t need to be intentional to be hurtful.

In 2013 the only person who mentioned that complaint was the guy telling me it was no big deal.

In 2016 a small martial arts school decided to build a welcoming and inclusive place for everyone, and their results speak for themselves.

In 2020 one of my heroes left the MVP program.

I suspect that in 2020 there are young women and brilliant people from other underrepresented groups who are questioning if the MVP program has a place for them.

Communities are defined by the behaviors they tolerate.

One community in this story chose to make diversion and inclusivity a true priority, and one apparently did not. One invested time and money and careful thought in “actively and aggressively building… a safe space for all,” and the other one apparently did not.

I hope the MVP program will recognize this moment for the wake-up call it is. I hope the MVP program will choose to change and grow.

But it needs to be a choice.

Hey, look – no swearing after all. Good on me[8].


[1] The MVP Summit is an NDA event, which is one of the things that makes is to much fun.

[2] If this phrase feels immediately inappropriate as you read this today, I would like to share this MacMillan Dictionary post from the general timeframe of this event that calls this phrase “a vividly effective metaphor for conveying transparency and frankness” which nicely sums up my intent.

[3] The same brain that made it hard for me to know who might have been offended by my presentation also makes it hard for me to remember the male MVP who let me know about the complaint. Faces and names have always been hard for me.

[4] Not to say that they don’t exist – there’s a universe of stuff out there I don’t know about. If you know of a vibrant and inclusive technical community, please tell me.

[5] HEMA stands for Historical European Martial Arts, which is a blanket term for the modern swordplay practice I love so much. The HEMA community has enough “bad apples” to drive away many people who would love it as much as I do, including sexism, racism, and more. That community is starting to change and grow, and Valkyrie is part of the reason. There are some other delightful folks in this community who take no bullshit, and I love them too. If you want to imagine what the abusive behavior looks like, watch Karate Kid, but give the Cobra Kai dudes swords.

[6] If you don’t believe me, check out this great presentation from Jasmine Orange on “Designing for the ten percent.”

[7] Look it up yourself – do a little legwork on this one, bro.

[8] This was a rough post to write – it’s difficult to talk about hurtful mistakes even if they’re years in the past. I like to think I am a better person than I was a year or a decade ago, but I still make mistakes. I still act thoughtlessly and carelessly, and I still fail to live up to the moderately lazy standards I set for myself. But I’m trying, and the people in my life are forgiving.

One report for multiple audiences

Have you ever needed to build a Power BI application that make insights and data available for use used by multiple groups of users, where those user groups have some overlapping needs, but also some exclusive needs?

Maybe requirements like these?[1]

  • A dataset with sales data that needs to be used by store managers and district managers
  • A sales report that contains both store-level and district-level pages
  • Each district manager should see only data from stores in their districts
  • Each store manager should see only data from their store
  • District managers should see all pages
  • Store managers should see only store-level pages

Until we got to the last two requirements, you were probably thinking about row-level security, but then you may have started to have doubts. Hold that thought.

Image by Tayeb MEZAHDIA from Pixabay

First and foremost, protecting data at the source is the most reliable way to prevent unauthorized users from accessing what they are not entitled to see. Hiding elements in the UI layer is not a security mechanism and should never be treated as one.

Let’s make that stand out a little more with some fancy formatting.

Protecting data at the source is the most reliable way to prevent unauthorized users from accessing what they are not entitled to see. Hiding elements in the UI layer is not a security mechanism and should never be treated as one.

Sometimes security isn’t everything you need – sometimes you need a targeted or adaptive user experience as well. This just got a little easier with Power BI and some recently released capabilities for conditional formatting.

Here’s the short version:

Using some of the same techniques you use for row-level security, you define roles in your data model that say what users can see what pages. You hide the pages in your report, and you implement navigation controls in your report using buttons on report page surface. When you publish the report, you define row-level security rules in the report dataset to identify what users and groups belong to which roles, which in turn are used for the conditional formatting used to control report navigation.

Here’s the long version: Read these blog posts from Gilbert Quevauvilliers and Marc Lelijveld.

Marc and Gilbert both go through step-by-step detail and each one explains the approach slightly differently, so I recommend reading each of their posts. They’ve saved me the trouble of writing up something detailed myself.

This approach gives you another tool in your Power BI tool belt, and may be useful if you’re trying to reduce the number of reports you manage and want to customize a single common report for multiple audiences.


[1] This is a generic example with generic data and roles, but the actual scenario details seem to be common across industries and data domains. I’ve heard variations on this theme from enough customers to believe that this is a common use case.

Foster Kittens and Managed Self-Service BI

My family is a foster family for cats and kittens from the cat shelter where we’ve adopted some of our own cats. Usually a litter will stay with us for a month or two, but it depends on the kittens themselves, and on external factors.

While the kittens are with us, it’s our responsibility to help them grow, both physically and socially. The experts at the shelter are always available if we need help, but for the most part we have the knowledge and tools we need to be successful. In many cases we’re their first real exposure to humans, and we can prepare them to be loving and playful members of a family. Just not our family.

Once the kittens are ready to be adopted, we take them to the shelter, where they will be carefully matched with their forever family. This last part is important – it’s hard enough to let go, and knowing that each of them will find a good home is what makes it possible.

It’s really the best of both worlds – kind of like managed self-service BI with Power BI.[1]

 

Not unlike fostering kittens, managed self-service BI can be the best of both worlds. As an analyst working in Power BI, you can often pick up projects when the scope is still small and manageable, and when you can have fun playing around with the data and seeing what it’s likely to become.

I’m emphasizing the “managed” in managed self-service BI, because it’s best to not be completely on your own. Having someone backing you up, someone with the expertise and resources to get you through challenging spots with a helping hand, is just as important with BI as it is with kittens. An author on his own may make avoidable mistakes with long-term consequences, but a center of excellence or community of practice can provide training up front, and assistance along the way so the finished self-service solution is ready to grow up – and growing up is an important goal.

Just as my family includes our adult cats, that analyst working in Power BI has a day job. If we kept each litter of kittens we foster, things would soon become messy and unmanageable. If an analyst retained ownership of every Power BI solution he developed, he would struggle to stay on top of his core priorities.

Being able to hand off a self-service solution to a central BI team is what gives this story a happy ending. The BI team can give the analyst’s work the long-term home it deserves, and the analyst can get back to his job… while also keeping an eye open for the next self-service BI challenge to come along and steal his heart.

Of all the kittens I have loved, I miss Tiny the most.
Your head. I will bite it now.[2]
If you’re interested in learning more about the shelter where we volunteer, please visit the Meow Cat Rescue web site. Please also consider donating while you’re there – the global pandemic is making it harder for their awesome staff and volunteers to do what they do, and kitten season is upon us. If you appreciate the BI Polar blog and its companion YouTube channel, there’s no better way to say thank you than to donate to Meow. Even a small donation will help.


[1] I hope you saw that one coming

[2] This footage of Tiny attacking my head didn’t fit into the Power Kittens video, but I shared it on Twitter because it was just too cute to not share.