Fabric Lakehouse Governance & Data Lineage

If you’ve ever wondered why your data suddenly disappears from a report, or who exactly changed the source file feeding your monthly dashboard, you’re not alone. Most teams are flying blind when it comes to seeing the full journey of their data.Today, we’re going to trace that journey inside Microsoft Fabric — from ingestion, through transformation, into analytics — and uncover how lineage, permissions, and the catalog work together to keep you in control. By the end, you’ll see every hop your data makes, and exactly who can touch it.Seeing the Invisible: The Path Data Actually TakesMost people picture data traveling like a straight road: it leaves the source, passes through a few hands, and ends up neatly in a report. In reality, it’s closer to navigating an old building that’s been renovated a dozen times. You’ve got hallways that suddenly lead to locked doors, side passages you didn’t even know existed, and shortcuts that bypass major rooms entirely. That’s the challenge inside any modern analytics platform—your data’s path isn’t just a single pipeline, it’s a web of steps, connections, and transformations. Microsoft Fabric’s Lakehouse model gives the impression of a single, unified home for your data. And it is unified—but under the hood, it’s a mix of specialized services working together. There’s a storage layer, an analytics layer, orchestration tools, and processing engines. They talk to each other constantly, passing data back and forth. Without the right tools to record those interactions, what you actually have is a maze with no map. You might know how records entered the system and which report they eventually landed in, but the middle remains a black box. When that black box gets in the way, it’s usually during troubleshooting. Maybe a number is wrong in last month’s sales report. You check the report logic, it looks fine. The dataset it’s built on seems fine too. But somewhere upstream, a transformation changed the values, and no one documented it. That invisible hop—where the number stopped being accurate—becomes the needle in the haystack. And the longer a platform has been in use, the more invisible hops it tends to collect. This is where Fabric’s approach to lineage takes the maze and lays down a breadcrumb trail. Take a simple example: data comes in through Data Factory. The moment the pipeline runs, lineage capture starts—without you having to configure anything special. Fabric logs not just the target table in the Lakehouse but also every source dataset, transformation step, and subsequent table or view created from it. It doesn’t matter if those downstream objects live in the same workspace or feed into another Fabric service—those links get recorded automatically in the background. In practice, that means if you open the lineage view for a dataset, you’re not just seeing what it feeds—you’re seeing everything feeding it, all the way back to the ingestion point. It’s like tracking a shipment and seeing its path from the supplier’s warehouse, through every distribution center, truck, and sorting facility, instead of just getting a “delivered” notification. You get visibility over the entire chain, not just the start and finish. Now, there’s a big difference between choosing to document lineage and having the system do it for you. With user-driven documentation, it’s only as current as the last time someone updated it—assuming they remembered to update it at all. With Fabric, this happens as a side effect of using the platform. The metadata is generated as you create, move, and transform data, so it’s both current and accurate. This reduces the human factor almost entirely, which is the only way lineage maps ever stay trustworthy in a large, active environment. It’s worth noting that what Fabric stores isn’t just a static diagram. That automatically generated metadata becomes the basis for other controls—controls that don’t just visualize the flow but actually enforce governance. It’s the foundation for connecting technical lineage to permissions, audit trails, and compliance cataloging. When you hear “metadata,” it can sound like passive information, but here it’s the scaffolding that other rules are built on. And once you have that scaffolding in place, permissions stop being static access lists. They can reflect the actual relationships between datasets, reports, and workspaces. Which means you’re not granting access in isolation anymore—you’re granting it with the full context of where that data came from and where it’s going. That’s where lineage stops being just an operational tool for troubleshooting and becomes a strategic tool for governance. Because once you can see the full path every dataset takes, you can make sure control over it travels just as consistently. And that’s exactly where permission inheritance steps in.One Permission, Everywhere It MattersImagine giving someone permission to open a finished, polished report — only to find out they can now see the raw, unfiltered data behind it. It’s more common than you’d think. The intent is harmless: you want them to view the insights. But if the permissions aren’t aligned across every stage, you’ve just handed over access to things you never meant to share. In the Lakehouse, Microsoft Fabric tries to solve this with permission inheritance. Instead of treating ingestion, storage, and analytics as isolated islands, it treats them like rooms inside the same building. If someone has a key to enter one room, and that room directly feeds into the next, they don’t need a separate key — the access decision flows naturally from the first. The model works by using your workspaces as the control point. Everything in that workspace — whether it’s a table in the Lakehouse, a semantic model in Power BI, or a pipeline in Data Factory — draws from the same set of permissions unless you override them on purpose. In a more siloed environment, permissions are often mapped at each stage by different tools or even different teams: one team manages database roles, another manages storage ACLs, another handles report permissions. Over time, those separate lists drift apart. You lock something down in one place but forget to match it in another, or you remove a user from one system but they still have credentials cached in another. That’s how security drift creeps in — what was once a consistent policy slowly turns into a patchwork. Let’s make this concrete. Picture a Lakehouse table holding sales transactions. It’s secured so that only the finance team can view it. Now imagine you build a Power BI dataset that pulls directly from that table, and then a dashboard on top of that dataset. In a traditional setup, you’d need to manually ensure that the Power BI dataset carries the same restrictions as the Lakehouse table. Miss something, and a user with only dashboard access could still query the source table and see sensitive details. In Fabric, if both the Lakehouse and the Power BI workspace live under the same workspace structure, the permissions cascade automatically. That finance-only table is still finance-only when it’s viewed through Power BI. You don’t touch a single extra setting to make that happen. Fabric already knows that the dataset’s upstream source is a restricted table, so it doesn’t hand out access to the dataset without verifying the upstream rules. The mechanics are straightforward but powerful. Because workspaces are the organizing unit, and everything inside follows the same security model, there’s no need to replicate ACLs or keep separate identity lists in sync. If you remove someone from the workspace, they’re removed everywhere that workspace’s assets appear. The administrative load drops sharply, but more importantly, the chances of accidental access go down with it. This is where the contrast with old methods becomes clear. In a classic warehouse + BI tool setup, you might have a database role in SQL Server, a folder permission in a file share, and a dataset permission in your reporting tool — all for the same logical data flow. Managing those in parallel means triple the work and triple the opportunity to miss a step. Even with automation scripts, that’s still extra moving parts to maintain. The “one permission, many surfaces” approach means that a change at the source isn’t just reflected — it’s enforced everywhere downstream. If the Lakehouse table is locked, no derived dataset or visual bypasses that lock. For governance, that’s not a nice-to-have — it’s the control that stops data from leaking when reports are shared more widely than planned. It aligns your security model with your actual data flow, instead of leaving them as two separate conversations. When you combine this with the lineage mapping we just talked about, those permissions aren’t operating in a void. They’re linked, visually and technically, to the exact paths your data takes. That makes it possible to see not just who has access, but how that access might propagate through connected datasets, transformations, and reports. And it’s one thing to enforce a policy — it’s another to be able to prove it, step by step, across your entire pipeline. Of course, having aligned permissions is great, but if something goes wrong, you’ll want to know exactly who made changes and when. That’s where the audit trail becomes just as critical as the permission model itself.A Single Source of Truth for What Happened and WhenEver try to figure out who broke a dashboard — and end up stuck in a reply-all thread that keeps growing while no one actually answers the question? You bounce between the data team, the BI team, and sometimes even the storage admins, piecing together guesses. Meanwhile, the person who actually made the change is probably wondering why the metrics look “different” today. This is the part of analytics work where the technical problem turns into a game of office politics. Audit logs are Fabric’s way of taking that noise out of the equation. They act like a

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365–6704921/support.

If this clashes with how you’ve seen it play out, I’m always curious. I use LinkedIn for the back-and-forth.