Power BI Overview
One platform from data pull to governed sharing
Power BI is Microsoft's end-to-end BI platform: Power Query for data prep, a tabular model for relationships, DAX for measures, report designer, and the Power BI service for publishing, sharing and governance.
What you will learn
- Name the four pillars: Power Query, data model, DAX, report rendering
- Describe Desktop versus the service vs Fabric/embedded
- Trace a dashboard from source to shared workspace
What is this?
Power BI is Microsoft's BI platform: Power BI Desktop builds datasets and reports locally; the Power BI service publishes, refreshes and shares those artifacts in Capacity-backed workspaces; DAX computes measures; and enterprise features (dataflows, pipelines, RLS, embedding) stretch it from personal tool to governed platform. It runs on the Analysis Services tabular engine for fast in-memory models.
Why do you need it?
- It is ubiquitous in mid/large companies — a foundational skill for BI professionals.
- The combination of a real tabular model + robust server/refresh + governed sharing makes it production-grade.
- Fabric integration continues to blur line between warehouse and BI.
- Certification, RLS and deployment pipelines answer 'governed at scale' demands.
Mental model
A car mechanic's integrated bay and road test
Power BI Desktop + service
You tune in the garage (Desktop: prep, model, design), then the car goes to the fleet depot (service: publishing, refresh, security) where every vehicle is maintained, tracked and given out per policy.
How it works
- Power Query imports and shapes source data (files, DBs, APIs).
- The in-memory tabular model stores tables, relationships and measures.
- DAX measures compute metrics at query time within filter context.
- Reports combine pages, visuals, bookmarks and drillthrough from the model.
- Publishing uploads the PBIX (and dataset) to a workspace on the service.
- The service schedules refresh, applies RLS, shares via apps, and tracks usage.
From Desktop to platform.
In production
- A sales team publishes a dataset refreshed nightly from a warehouse and shares an app of dashboards over it.
- Finance uses RLS so region managers see only their region's rows of a shared P&L dataset.
- IT runs deployment pipelines to move reports from dev to test to production environments.
Best practices
- Do heavy transformation in the warehouse; keep Power Query for light shaping.
- Design the model (relationships, measures) before the visuals — the model is the asset.
- Put measures in the model, not in visuals (DAX expression reuse).
- Publish to governed workspaces with RLS, refresh and usage monitoring.
Common mistakes
- Loading raw production tables and re-Shaping everything in Power Query forever.
- No surrogate keys and many-to-many relationships modeled as one-to-many.
- Measures duplicated inside visuals becoming impossible to audit.
- Sharing reports outside governed workspaces with no RLS or refresh owner.
Common issues
Refresh fails in the service but works in DesktopGateway not configured or credentials not scoped for the publish
Install/configure the on-prem gateway and set use-app-credentials with the right scoping.
Measure returns wrong aggregateDAX evaluated in a filter context you didn't expect (relationship filtering)
Trace with CALCULATE and ALL; verify active relationships and row context.
Debugging tips
- Wrong numbers → check the model relationships and the DAX first, then the transform.
- Slow refreshes → reduce full loads; push cleansing upstream.
- Service refresh fails → check gateway/lifetime and credential scope settings.
Interview checkpoint
Quick quiz
Which Power BI layer is responsible for scheduled refresh and row-level security?
Power BI Desktop can perform both data shaping and report building.