A client portal with Power BI Embedded

By the fifth year of building a BI practice inside a consulting firm that serves private schools in Brazil, the data was no longer the hard part. Python scripts handled the processing, the reports read from SQL Server, and the team had grown to four people. What still needed work was the last step of the chain: how a finished report reached the person who had asked for it.

This post is part of a series on six years building a BI practice. It covers year five, when I built a web portal around Power BI Embedded and the BI work started to live outside the consulting projects that had created it.

Where the client area started

The portal grew out of something older. In my first year, one of my first assignments was a client area where the firm could share the results of its consulting work. At the same time, I was moving every report we produced into Power BI. I wrote about that beginning in Power BI as a product.

That first client area proved one thing early: clients noticed the clearer, interactive view of their own data, and they valued it. It turned BI into a line in our portfolio instead of a side task.

Four years later the situation was different. Processing was automated, the reports were faster, and we had people to look after them. So the goals for year five were about the reader. I wanted a better experience for the people opening the reports, and I wanted a product that could stand on its own, beyond the consulting engagements.

Why sharing is the hard part

Building a report is a solved problem. Getting it in front of someone outside your company, safely, is where many BI projects stall.

The tempting shortcut is publish to web. It produces a link that anyone can open, with no sign-in at all. For public data that is fine. For anything confidential it is the wrong tool, because the link is the only lock. A school's survey results or financial figures should never be one forwarded message away from a stranger.

The other route is to bring every reader into the BI tool itself, on the client's side, with their own access to manage. That shifts the work to people who just want to read a dashboard. Every new reader becomes a new setup task, and the experience depends on how comfortable each school is with a tool it never chose.

Neither option matched what I wanted: the client opens a page, signs in, and sees their reports, without learning anything new.

How the portal worked

The model we used is the one Microsoft calls embed for your customers, also known as app owns data. It sounds technical, but the logic fits in four lines:

• The client signs in to our application, not to Power BI.
• Our application authenticates with Power BI on its own, through a service principal, and requests the reports that this client is allowed to see.
• The reports run on capacity that we, the provider, pay for.
• The people viewing the reports don't need a Power BI license of their own.

The application was a Python web app built with Flask, with a front end in plain JavaScript, HTML and CSS. Nothing exotic, and that was deliberate. Python already ran our data processing, so the portal and the pipelines spoke the same language, and anyone on the team who could read one could follow the other.

The front end wrapped the embedded reports in our own pages, so the client saw one product instead of a patchwork of tools.

What changed

The first effect showed up on our side. Report maintenance became simpler, because the reports and the way clients reached them now lived in one system that we controlled.

The second effect was on the client side. People got secure, practical access to their own information. They signed in to one portal and found what was theirs, without depending on anyone to send them a file or a link.

Then came the number. The growth that followed was 400%. I don't credit the portal alone for that. It sat on top of a year of automation and a larger team, and without those the portal would have been a nice front door to a slow building. But it was the piece that let BI work as a product clients used on their own, outside the consulting projects.

What I would do again

Looking back, a few decisions from that year still hold up, and I would make them the same way today.

• Treat delivery as part of the BI work, not as an afterthought. A report that is hard to reach is a report people stop opening.
• Let clients sign in to your product, not to the BI tool. Authentication and capacity stay on your side, where you can manage them.
• Never put private data behind a public link, even for a quick test. Quick tests have a way of becoming permanent.
• Build with the stack your team already runs. For us that was Python, so Flask was the shortest path from idea to working portal.
• Start with something small. The year-one client area came first, and the portal grew out of it. Years of real use came before the first line of portal code.

The same idea, sharing your BI with people outside the company without making them part of it, is what the bi19 BI platform does today: it shares dashboards and Power BI reports with people outside your organization. The last part of this series covers the year the work shifted from systems to people: leading a BI team.