Getting Started with Microsoft Fabric and Power BI - What You Need to Know

If you're a Power BI user who keeps hearing about Microsoft Fabric and isn't sure whether it matters to you, here's the short version - it does, and the learning curve is smaller than you think.

I've been working with Australian organisations on their data analytics stack for years, and the shift from standalone Power BI to Fabric-integrated Power BI is the biggest change since Power BI moved to the cloud. Not because the reporting changes dramatically, but because everything underneath it gets better. Your data lives in a lakehouse instead of scattered across import files and dataflows. Your pipelines are real pipelines with error handling. Your semantic models connect directly to the lakehouse through Direct Lake mode, which means you get near-import performance without actually importing the data.

Microsoft's tutorial for Power BI users getting started with Fabric covers the mechanics well. But I want to fill in what the tutorial doesn't tell you - what this means in practice, where it helps, and what to watch out for.

The Lakehouse Concept - Why It Matters

If you've been using Power BI with Import mode or DirectQuery against a SQL database, the lakehouse concept might feel unfamiliar. A lakehouse is essentially a storage layer that combines the flexibility of a data lake with the structure of a data warehouse. Your data lives in open formats (Delta/Parquet files) and you can query it with SQL, Python, Spark, or connect to it from Power BI.

Why should a Power BI user care? Because it solves the "where does the data live?" problem that plagues most Power BI deployments.

Right now, if you're doing data prep in Power BI, your transformations are baked into the .pbix file or a Power BI dataflow. If another team needs the same data, they either duplicate the work or connect to your dataset. Neither option is great. With a lakehouse, the prepared data sits in one place, and multiple reports, teams, and tools can consume it.

In the tutorial, Microsoft has you create a "SalesLakehouse" and load data into it using Dataflows Gen2. That name change from "dataflows" to "Dataflows Gen2" is worth paying attention to. Gen2 dataflows output to a lakehouse rather than to the Power BI storage. The data ends up as proper tables you can query with SQL, not just blobs hidden inside Power BI's internal storage.

Dataflows Gen2 - The Familiar Part

If you've used Power BI dataflows before, Dataflows Gen2 will feel familiar. You still use Power Query to shape and clean data. The interface is essentially the same. The difference is where the data goes.

In the tutorial, you import a Power Query template (.pqt file) containing Contoso sales data, adjust the date types, and configure destinations. The key decision here is the update method - Replace or Append.

For dimension tables (DimDate, DimCustomer, DimProduct), Replace makes sense. These tables are relatively small and you want a clean copy each time. For fact tables like FactOnlineSales, you want Append because you're adding new transactions without wiping existing data.

This is a pattern we see constantly in client work. Getting the update method wrong means either losing historical data (Replace on a fact table) or ending up with duplicates (Append on a dimension table that changes). The tutorial handles this correctly, but in real projects you need to think carefully about each table.

One thing I wish the tutorial mentioned more explicitly - if you're using Append mode, you need a strategy for handling late-arriving data and corrections. What happens when last month's invoice gets adjusted? Append won't update existing rows. You'll need a separate process to handle updates, or switch to an upsert pattern using notebooks or stored procedures.

Pipelines - Finally, Proper Orchestration

This is where Fabric adds something Power BI genuinely didn't have before. The tutorial has you create a data pipeline that refreshes the dataflow and sends an email if it fails. That might sound basic, but think about what most Power BI teams do today for orchestration - they schedule a refresh in the Power BI service and hope it works. When it fails, someone notices the next morning because the report shows stale data.

The pipeline pattern gives you actual error handling. The tutorial's example sends an Outlook email on failure, which is a start. In production, we typically add Teams notifications, logging to Application Insights, and retry logic for transient failures.

The expression builder in Fabric pipelines supports dynamic content, so your failure email can include the pipeline ID, workspace ID, and timestamp. Small thing, but when you're troubleshooting at 7am because the overnight refresh failed, knowing exactly which pipeline in which workspace broke saves real time.

We schedule these pipelines to run daily (the tutorial uses midnight), but you can go as granular as you need. Some of our manufacturing clients run hourly refreshes during production hours and daily refreshes overnight.

The Semantic Model and Direct Lake

Here's where things get genuinely exciting for Power BI users. In the tutorial, you create a semantic model directly from the lakehouse tables. This model uses Direct Lake mode, which is a third option alongside Import and DirectQuery.

Import mode copies data into the Power BI model and gives great performance but has size limits and requires scheduled refreshes. DirectQuery queries the source live and has no size limits but is slower and puts load on the source system. Direct Lake reads data directly from the lakehouse's Delta tables with near-import performance. No data copying, no source system load, and the data is always current.

There are caveats. Direct Lake falls back to DirectQuery for certain DAX patterns. If your measures are complex or you're using many-to-many relationships, you might see performance degrade. We've found that for straightforward star schemas - which is what you should be building anyway - Direct Lake works well.

The tutorial has you build relationships manually between the fact and dimension tables. This is the standard star schema pattern - FactOnlineSales in the centre, dimensions connected through key columns. If you've built dimensional models in Power BI Desktop before, this is identical. The only difference is you're doing it in the browser rather than in Desktop.

One relationship detail from the tutorial worth highlighting: the DimStore to DimEmployee relationship uses bidirectional cross-filtering. This allows filters to flow both ways, which is necessary when you want to filter stores by employee attributes. Bidirectional filtering has performance implications though, so use it only when needed.

What the Tutorial Doesn't Cover

A few things missing from the tutorial that matter in production:

Security. Row-level security in Fabric works differently than in Power BI Premium. You'll need to set up workspace roles and potentially object-level security in the lakehouse. This is worth planning before you start migrating production data.

Cost. Fabric uses a capacity-based pricing model. If you're currently on Power BI Pro, the jump to Fabric capacity is significant. Run a trial first and understand what capacity unit (CU) you actually need. Microsoft offers a free trial, which is enough to evaluate but not to run production workloads.

Migration path. The tutorial starts fresh, but most organisations have existing Power BI reports. Moving from Import mode to Direct Lake isn't a simple switch - you'll need to rebuild your data pipeline to load into a lakehouse, recreate your semantic model, and update your reports to use it. Plan this as a project, not a quick change.

Governance. With data centralised in a lakehouse, you need to think about who can modify tables, who can create dataflows that write to the lakehouse, and how you handle schema changes. The tutorial creates everything in one workspace, but production deployments typically separate development, staging, and production.

Should You Start Now?

If you're an Australian organisation currently running Power BI and wondering whether to adopt Fabric, my honest assessment is - start learning now, but don't rush to migrate production workloads.

Fabric is clearly where Microsoft is heading. The Power BI service will keep working, but the new features, the performance improvements, and the integration capabilities are all landing in Fabric first. Waiting too long means you'll have more to migrate later.

The tutorial is a good starting point. Spin up a trial, work through the steps, and build a feel for how lakehouses, dataflows, and pipelines fit together. If you have a new analytics project starting soon, consider building it on Fabric from day one rather than retrofitting later.

For teams that need help with the transition, our Microsoft Fabric consultants have been working with the platform since its preview release. We also do Power BI consulting for organisations that need to modernise their existing reports and data models, whether that's on Fabric or not.

The gap between "using Power BI" and "using Power BI on Fabric" is narrower than most people expect. The query language is the same. The report builder is the same. The DAX is the same. What changes is the plumbing underneath - and that plumbing is genuinely better.