Power BI & Fabric

'Power BI is slow / who can see this / why did it cost that' are four different objects' problems. Separate the report from the semantic model from the workspace from the capacity and every Power BI question routes to the right layer.

Power BI licensing is the single most-asked, most-misunderstood topic — because it combines a per-USER licence with a per-CAPACITY one, and the interaction has a famous threshold. Here it is, cleanly.

A workspace is where Power BI permissions actually live, and it has exactly four roles that most people conflate. Get the role ladder straight, then separate it from per-item sharing and app distribution — three different ways to grant access, three different blast radii.

The semantic model — renamed from 'dataset' — is where the real engineering lives: the tables, relationships, and DAX that every report reads from. Understand the VertiPaq columnar engine and the star schema and you understand why reports are fast or slow, right or wrong.

The Fabric admin portal is the single pane where the whole Power BI/Fabric tenant is governed: 170+ tenant settings, capacities, workspaces and domains. Learn its structure, who holds the admin roles, and how governance delegates downward.

How a semantic model connects to its data is the single biggest architectural decision: Import caches everything for speed, DirectQuery queries the source live, and Direct Lake is Fabric's new path that reads OneLake files directly. Each buys speed or freshness at the other's expense.

Data rarely goes straight from source to semantic model — it is shaped first. Dataflows do reusable Power Query prep in the service, Fabric pipelines and lakehouses do heavier engineering, and OneLake is the one storage layer they all write to.

Import models show a snapshot, so they must be refreshed on a schedule — and when the data lives behind the firewall, refresh runs through the on-premises data gateway. Both are quiet single points of failure that leave reports confidently showing yesterday's numbers.

DAX is the language behind every measure, and it is where 'the report is slow' usually resolves. Understand filter context and the storage-engine/formula-engine split, learn the classic performance killers, and use Performance Analyzer to find the visual actually to blame.

Fabric's admin portal holds 170+ tenant settings, and a handful of them are the difference between governed analytics and a data-leak waiting to happen. The ones that matter, how delegation works, and why they drift.

RLS and OLS live in the semantic model and decide which ROWS and which TABLES/COLUMNS each user can see through the same report. They are powerful and easy to get subtly wrong — which is why the testing discipline matters as much as the rules.

Sensitivity labels bring Purview's classification and protection into Power BI, so a 'Confidential' semantic model stays Confidential when someone exports it to Excel. Understand label inheritance, export enforcement, and the DLP policies that scan Power BI content.

There are several ways to get a report in front of people, and they differ enormously in blast radius: an app audience is governed distribution, a direct share is a personal grant, and publish-to-web is a public leak. Knowing which is which is the whole game.

Fabric capacity is the compute your workspaces run on, sold as F-SKUs measured in capacity units. Sizing it is a balance of workload demand, the F64 free-viewer threshold, and cost — get it wrong and you either throttle users or pay for idle CU.

Fabric doesn't just cut you off at the CU ceiling — it bursts to absorb spikes, smooths usage over time, and only throttles when you're persistently over budget. Understanding this model explains the mysterious 'reports were slow this afternoon' complaints.

You cannot manage capacity you can't see, and the Fabric Capacity Metrics app is the instrument. Learn to read its CU, throttling and top-operations views so you can find the noisy workload and act before users hit an interactive delay.

Fabric's shared-capacity model makes cost easy to lose control of — one bill, many consumers. Governing it means attributing CU to teams, using pausing and reservations, and making the F64-vs-Pro decision deliberately rather than by accident.

Editing reports straight in production is the BI equivalent of coding on the live server. Deployment pipelines give BI proper dev/test/prod stages, and Fabric Git integration adds real source control — together they make analytics releasable, reviewable and reversible.

You can't govern or justify what you can't measure. Power BI's activity log and usage metrics tell you who viewed what, what changed, and which expensive content nobody uses — the raw material for both security audit and the adoption/ROI story.

Clicking through the admin portal doesn't scale to a real estate — governance has to be automated. The Fabric/Power BI admin REST APIs, the metadata scanner, and app-only service-principal auth are how tools (serv365 included) read and watch the whole tenant unattended.