Power BI for Azure Users - A Practical Starting Guide

If your business already runs on Azure, you are sitting on more reporting capability than you probably realise. The data is there. The compute is there. What is often missing is the layer that turns it into something a human actually wants to read on a Monday morning. That layer, in most Australian organisations we work with, ends up being Power BI.

I want to walk through how Azure users should approach Power BI, because the official Microsoft documentation does a decent job listing the connection points but it does not really tell you what to do first, what to skip, and what tends to go wrong six months in. After running these projects for clients across mining, financial services, healthcare and government, we have a fairly opinionated view on this.

Why Power BI keeps winning in Azure-heavy environments

The honest reason Power BI dominates Azure reporting is not that it is the best visualisation tool on the market. Tableau still has the edge on certain advanced charting. Looker has stronger semantic modelling for some use cases. Power BI wins because it is already in the licence agreement, it talks to Azure SQL and Synapse without making you write a single line of glue code, and the people you already employ probably know it.

That is the practical reality. Australian businesses are not selecting Power BI after a six-month evaluation. They are selecting it because the CFO got an email about E5 licences and someone in finance has been building reports in it since 2019.

This is fine. The point is to use it well, not to apologise for choosing it.

The first three connections to make (and why)

Microsoft lists about a dozen Azure sources you can plug into Power BI. In our experience, three of them carry 90 percent of the value for most organisations.

Azure SQL Database is the obvious one. Direct Query mode lets you point Power BI at your operational data without copying it into a separate analytics store. The trap here is performance. Direct Query feels like magic until your operational database starts getting hammered by a Power BI dashboard that 200 people are refreshing at 9am. We have walked into clients where the production OLTP system was being slowed down by a single report nobody could remember commissioning.

The fix is usually one of two things. Either you put a read replica in front of the dashboards, or you switch to Import mode with scheduled refresh and accept that the data is 30 minutes old. For finance reporting, 30 minutes old is almost always fine. For an operations dashboard tracking live logistics, it is not. You need to know which side of that line you are on before you build anything.

Azure Synapse Analytics is where things get interesting. If you have moved any meaningful data warehousing workload to Synapse, Power BI is the natural front end. The connection is genuinely good. What is less good is the cost behaviour. A poorly written DAX measure pointed at a dedicated SQL pool can light up consumption charges quickly. We had a client who burned through nearly $40,000 in unexpected Synapse compute in a single month because one analyst kept refreshing a dashboard that triggered full table scans. If you are working at this scale, you want our Microsoft Fabric consultants or Power BI consultants involved before you let analysts loose on the model.

Azure Cosmos DB is the one people forget. If you have NoSQL data sitting in Cosmos, you can absolutely visualise it in Power BI, though you usually want to land it in a relational shape first via Synapse Link or a custom pipeline. Cosmos is built for high-throughput operational workloads, not analytical scans. Treating it like a data warehouse will get expensive fast.

Where Azure cost reporting comes in

One of the more underused features is the Azure Consumption Insights connector. If you are spending more than about $5,000 a month on Azure, you should be pulling this into Power BI and reviewing it monthly. The native Azure Cost Management views are fine for a quick look. They are not fine for actually understanding why spend went up 12 percent last quarter.

Build a proper cost dashboard with breakdowns by resource group, by service category, by tag (assuming someone in your organisation tagged things properly, which they probably did not). Show the trend. Show the anomalies. We have saved clients tens of thousands of dollars a year just by giving them visibility into what was actually running.

Quick honesty check though. If your tagging discipline is terrible, this dashboard will be terrible too. Garbage in, garbage out. Fix the tagging first or accept that you will be looking at a column labelled "untagged" that contains 60 percent of your spend.

Embedded analytics - the option most people skip

Power BI Embedded is one of the more interesting parts of the platform and almost nobody uses it well. If you are building a SaaS product or a customer portal, you can embed Power BI reports directly into your application using your own authentication. Customers see analytics. They do not see Power BI branding. They do not need a Power BI licence.

The pricing model is per-capacity rather than per-user, which makes it attractive for products with lots of low-touch users. We have built this for a few clients in the financial services and logistics space. The technical lift is real but not enormous, and it tends to make a much better impression on customers than a hand-rolled charting library that breaks every time someone resizes their browser.

The catch is that the licensing maths gets weird as you scale. A small embedded deployment is cheap. A massive one with thousands of concurrent users requires a capacity SKU that gets pricey. Model your costs before you commit.

Power BI Report Server - still relevant in 2026

I include this because we keep encountering Australian organisations, particularly in government and regulated industries, who cannot send their data to the Power BI service for compliance reasons. Power BI Report Server is the on-premises alternative.

It is not as fast moving as the cloud service. New features land months later, sometimes not at all. AI features in particular are limited. But if you genuinely cannot move data off-premises, it works. Just do not pretend you are getting the same product as the cloud version.

If you are stuck in this situation and the constraint is older than your current compliance posture, it might be worth revisiting whether the constraint still applies. We have seen clients spend years on Report Server when their actual risk assessment would now permit the cloud service. Talk to your security team. Things have moved on.

The Azure Machine Learning angle

This is where the documentation gets thin and the reality gets interesting. You can plug Azure ML models into Power BI as part of a Dataflow or as a custom function. The use case is usually scoring. Take a customer record, run it through a churn model, surface the score in the report.

In our experience this works well for two scenarios. The first is where the model is stable and the predictions are part of a regular reporting workflow, like monthly customer churn risk. The second is where leadership needs to see model outputs in the same view as the underlying business data, which is a surprisingly common ask once you have any ML in production.

It works badly when people try to use it for real-time inference. Power BI is not built for that. If you need predictions in milliseconds, you want a proper API call from your application, not a Power BI Dataflow. We work with clients on the right shape for this in our Azure AI consulting service engagements.

The things that consistently go wrong

A few patterns we see over and over:

Reports get built by individual analysts in isolation, then accumulate until nobody knows which is the source of truth. By year three, you have 400 reports and 380 of them are wrong, outdated, or duplicates. Govern this early or accept the mess.

DAX gets written by people who learned it from YouTube videos. The measures look fine. They give wrong numbers under specific filter contexts. The business runs on these numbers for two years before someone notices. This is more common than you would think.

Refresh schedules pile up. By the time you have 50 datasets refreshing nightly, the gateway becomes a bottleneck and refreshes start failing silently. Monitor your gateway throughput before this becomes a problem.

Permissions get sloppy. Row-level security gets configured for one report and forgotten about for the next twelve. Sensitive data ends up visible to the wrong people. Audit this annually at minimum.

What to actually do this quarter

If you are early in your Power BI journey on Azure, the practical sequence is roughly this. Get one or two flagship reports working well from your most important data source. Build the muscle around governance, refresh management and DAX quality. Then expand.

Do not start by trying to migrate every legacy report from your old BI platform. Start with the reports that drive the most decisions and rebuild them properly. Everything else can wait.

If you want help with the Azure side of this, our Azure AI Foundry consultants and Microsoft AI consultants work across these stacks regularly. And if you are still figuring out what to even prioritise, the AI Opportunity Planner is a decent starting point for the broader data and AI strategy conversation.

Reference: Microsoft's Power BI for Azure users documentation covers the official connection points and product references.