Microsoft Fabric for Microsoft 365 Admins: What You Need to Know

M365 FM - Microsoft Fabric for Microsoft 365 Admins - What You Need to Know

00:00:00 Speaker: One day a new item shows up in your admin center fabric. Nobody asked you. Nobody sent a ticket. It was just there, sitting next to the apps you already managed. And here's what I want you to take from this episode. Fabric is a tenant level governance problem before. It's a data tool because you manage Microsoft three hundred sixty five as workloads exchange SharePoint teams. Each one is its own app with its own settings. Fabric doesn't work like that. It runs as one shared platform, one pool of compute, one bill. That's the model, and it's what we're taking apart today. If you want the admin view of data platforms, not the vendor tour, subscribe. But before we touch a single setting, we need to see where fabric actually sits. Sponsor segment, educational break, quick break. Every platform decision you make starts with one question where does the data live right now? If you've ever planned a mailbox migration, you know how this goes. The move itself is the easy part. The risk is in the planning that comes before it because wherever the data lands shapes every choice after. That's where Stella Migrator for Exchange fits. It's a tool built for moving mailboxes between environments. You can find the details at the link in the description worth keeping in mind as we go, because data location is exactly what fabric is about to change. Back to the platform. And the first structural question why fabric lands on the M365 admins desk. Start with where fabric lives. It lives inside your tenant. The same tenant your users sign into every morning. The same identity system. The same conditional access rules. The same compliance boundary you've spent years defining. Then there's the admin side. Fabric has its own admin portal, but it sits in the same family as the other admin centers you already use. The licensing comes out of the same pool, the same global admin roles. Reach into it. So who owns it? Here's where it gets tricky. Data teams will buy capacity. They'll turn on features. They'll build things. But the tenant belongs to you. And that gap between who builds and who owns is where this gets interesting. Think about how data platforms used to work. In the old model, a data platform was an Azure project. It had its own subscription, its own resource groups, its own owners, usually a small team in a corner of the business. If you were the M365 admin, you might never touch it. You might never even hear about it. It lived next to your tenant, not inside it. That wall was real. It kept the two worlds apart. The new model removes the wall. Fabric is software as a service. There's no subscription to set up, no virtual network to build, no servers to size. You turn it on and it's running on your identity inside your compliance boundary next to your Microsoft three hundred sixty five data. That's a good thing for speed, but it changes who's responsible, because every shortcut that made the old model slow was also a checkpoint. A subscription needed approval. A resource group needed a name. Someone had to say yes. Now nobody has to. So what typically happens is this someone on a data team hears about fabric. They open the portal, they start a trial, a workspace appears, then a second one, then someone connects a data source, maybe a SharePoint site, maybe a set of exports from a business system. Data lands in a lake, reports get built, people start sharing them. And then months later, someone from security asks a simple question who has access to this? Where did it come from? Is any of it sensitive? That's when governance starts after the data is already there, not because anyone was careless, because the platform made it easy and easy has no checkpoint built in. That's the pattern you're here to prevent, and you can't do it by blocking fabric. Teams will find another route or they'll push back until you give in. What works is understanding the structure well enough to set the guardrails early, before the first workspace, before the first data set. You don't need to become a data engineer for that. You need to know five things how compute is shared, where the data sits, how access is layered, what the settings control, and what each person is paying for. Your skills already apply here. Identity licensing compliance policy. You've been doing this for years, just with different names on the boxes. What's new is that these pieces now sit on top of a platform that moves data around by design. So to see how those pieces connect, we need one simple picture. First, a mental model you can hold in your head while we go through the rest. The mental model. Event. Reasoning. Orchestration. Here's the picture. Three steps. Event reasoning. Orchestration. Every piece of fabric fits one of them. And once you see that the platform stops looking like a pile of product names, start with the event. Something happens and data shows up. A file lands in SharePoint, a sales system writes a new row. A stream of sensor readings arrives every second in fabric. This step is about getting data in pipelines. Copy it. Streams. Catch it, shortcuts point at it, and all of it ends up in one place, which we'll get to in a few minutes. Nothing smart has happened yet. The data just arrived. Now the reasoning. This is where the data gets shaped and interpreted. Someone cleans it. Someone joins it with other data. Someone writes code to calculate something or builds a model on top of it, or asks a question in plain language. In fabric, that's notebooks, warehouses, lake houses, and the semantic models behind reports. This is the step people mean when they say data work and then orchestration. The data is shaped. Now it needs to move on a schedule in the right order to the right place. Refresh the model at six. Run the clean up before the report updates. Send an alert. If something fails, that's pipelines and triggers and refresh schedules. The part that turns a one time analysis into something a business can rely on. So the flow is simple. Data arrives, data gets shaped, data gets delivered again and again without anyone clicking a button. Now here's why I'm giving you this. You don't need to name every feature in each step. Fabric has a lot of them, and the list keeps growing. If you try to memorize it, you'll be out of date by next quarter. But if someone says we're adding a new workload, you can ask one question which step does it belong to? Does it bring data in? Make sense of it, or move it along? That question tells you what it touches and what it touches tells you what to govern. Because here's where you sit in this picture, not inside any one step around all three identity wraps them. The same person who ingests the data may reason over it and schedule it. Capacity wraps them to all three steps. Draw compute from the same pool and policy wraps them because a label or a sharing rule has to follow the data through every step, not just the one where someone remembered to apply it. Think of it as a layer that runs underneath the whole flow. That's your layer. Now compare this with what you already manage. Exchange is one workload. It does mail. You can describe its whole job in one sentence. SharePoint is one workload. It stores and shares content. Teams is one workload. Each has its own settings, its own limits, its own admin page. If exchange has a problem, it's an exchange problem. Fabric doesn't split up that cleanly. A slow report might trace back to a heavy notebook running in a different workspace. A failed refresh might come from an ingestion job that ate the shared compute an hour earlier. A leak in the last step might start with a permission granted in the first. The steps aren't separate apps. They're stages in one flow, running on one platform, drawing from one pool. That's why the old habit breaks. When you manage workloads, you tune each one in isolation. When you manage a platform, you manage the flow between them, what goes in, what it costs, who can see it at each stage. And that changes the questions you ask not, is this app configured correctly? But where does this data travel and what's wrapped around it at every stop? So keep the three steps in your head. Event reasoning orchestration will hang everything else on them. And the first physical thing all three steps share. The thing they all pull from is the capacity. What a capacity actually is. A capacity is a pool of compute. That's the whole idea. You buy a size, and everything assigned to it draws from that size, event, reasoning, orchestration. All three steps pull from the same bucket. Microsoft measures that bucket in capacity units. You'll see them written as queues, and F2 gives you two, and EF sixty four gives you sixty four. The number doubles as you go up, and so does the price. A capacity unit isn't a server or a machine. It's a measure of how much work the platform can do for you per second, and every action in fabric costs some amount of it. A notebook run costs units a report refresh costs units. A user clicking around in a warehouse costs units. Now here's the part people miss. One capacity serves many workspaces ten fifty one hundred. Every one of them draws from the same pool, and fabric doesn't carve it up fairly. There's no quota per workspace unless you build one by hand, and by default, nothing stops one team from using most of it. So the assumption that breaks is this one. More workspaces means more resources. It doesn't. A new workspace adds a place to put things. It adds zero compute. If you create twenty workspaces on one ef64, you have twenty places to work and still sixty four units to share. That sounds obvious when I say it out loud, but in practice, people see a fresh workspace and assume it comes with its own room to run. It doesn't. It borrows. Now let's talk about what you can actually buy because the names matter. The F SKUs are the mainline F two, F four, F eight all the way up. You buy them in Azure, you pay by the hour or reserve them for a year, and you can pause them there. The default choice today, the SKUs are the older power BI premium capacities. They still exist, and plenty of tenants still run them, but Microsoft stopped selling new ones. If you inherited a PC, you're in a legacy lane. It works. It just isn't where things are heading. Then there's the trial capacity. This one deserves your attention. A trial capacity is free. It's sized roughly like an F sixty four and it expires. Anyone with the right setting turned on can start one. And as we saw earlier, that's usually how the whole story begins. Someone starts a trial, builds something useful, and a few weeks later, the business depends on a thing that has a deadline attached. So for an admin, the three SKU families mean three different conversations. F means a bill you can control. P means a contract you should plan to move off. Trial means a clock you need to find before someone else notices it. Now why does one capacity matter so much? Because it's three things at once. It's a billing object. The cost of everything inside it lands on one line. That's useful because finance can see it. It's also limiting because you can't easily tell which department caused the charge. It's a performance boundary. Everything inside shares the same speed. When the pool is healthy, everyone's fast. When it's tight, everyone slows down together. A user in marketing has no idea that a data engineer in finance just started a heavy job. They only know their report is slow and it's a blast radius. That's the one I want you to hold on to. If one workspace runs something expensive or something broken, the damage doesn't stay in that workspace. It spreads across every workspace on the same capacity, same pool, same problem. You've seen this shape before in a smaller form. One noisy mailbox rule can slow a server, but there the server was the limit. Here, the limit is a number you chose when you bought the capacity, often without knowing what would run on it. So capacity isn't a technical detail you hand off to the data team. It's the first place where cost, speed and risk all meet in a single object. And because everything shares it, fabric needs a rule for what happens when the pool runs short. That rule has a name throttling, smoothing, bursting and throttling explained. Here's the first thing to know about how fabric measures usage. It doesn't look at the moment it looks at the window. Say a notebook needs a huge amount of compute for 30s on a fixed server that would hit a wall, fabric handles it differently. It lets the job run, then spreads the cost of that job across a stretch of time. That's called smoothing, so a short spike doesn't hurt you. The platform averages it out, and the thing that makes this possible is bursting. Bursting means a drop can use more compute than your capacity size. For a short time, you bought sixty four units. A heavy job might grab far more than that for a few seconds. It gets the speed it needs right now, but there's no free lunch here. Bursting borrows from the future. The units you overspent today get paid back out of the units you'd have used later. Smoothing is the repayment plan. It takes that one big charge and spreads it across the next minutes or hours or longer, depending on the type of work. Which brings up the word you need to remember carry forward. Carry forward is the debt. When a capacity spends more than it has, the extra doesn't disappear. It carries forward and it has to be paid off before the capacity runs clean again. As long as there's debt on the books. New work is competing with old work for the same units. That's why a bad Monday can slow Wednesday. Someone kicks off a big job on Monday afternoon. It runs fine. Nobody complains. But the cost was spread forward and the debt is still being paid down. Two days later, when a different team opens a report, that report is slow and nobody connects it to Monday because the cause and the symptom live on different days. Now not all work gets treated the same. Fabric splits operations into two types. Interactive operations are the ones a person triggers and waits on. A user opens a report. Someone runs a query. Someone clicks a button. These are smoothed over a short window, usually a few minutes. Background operations are the ones nobody's watching. Scheduled refreshes, pipeline runs, notebook jobs running overnight. These get smoothed over a much longer window, a full twenty four hours. The reasoning is simple a person waiting needs an answer. Now a scheduled job can take its time. So fabric lets background work spread its cost thin across the whole day, which keeps it from crowding out the people clicking around in real time. That's a smart design. It also hides a trap because a heavy overnight job looks cheap at any single moment. Its cost is spread so thin that no one sees a spike. But add up enough of those jobs, and the day's total quietly climbs toward your limit. So what happens when you reach it? Throttling comes in stages. It doesn't flip a switch first, the platform adds a small delay to new interactive work. Users notice that things feel sluggish. A page takes longer than it should. Most people shrug and refresh if the debt keeps growing. The next stage delays background work to refreshes. Start late, jobs queue up, and if the capacity stays overloaded, the last stage kicks in. Rejection. New work doesn't just slow down, it gets refused. Users see an error. Scheduled jobs fail outright, so the experience looks like this. Slow, slower than broken. And here's the part that lands on your desk. The user who hits the error is almost never the person who caused it. They open a report, they get a message, and they open a ticket with you. The cause might sit three workspaces away in a job that ran two days ago. That's the pattern. Cause and symptom separated by time and by team. Which means you can't fix this by looking at the person who complained. You need to see the pool itself. And Microsoft gives you a tool for exactly that monitoring capacity with the metrics app. There's an app for this Microsoft Fabric capacity metrics. You grab it from Appsource, install it into a workspace, point it at a capacity, and it builds you a report on that capacity usage. A capacity admin has to do the setup. Most users will never see it and that's part of the problem. So what does it actually show? Three things, mostly how much of the pool you're using over time, whether you've gone over and by how much and which items did the spending start? With utilization, you get a chart that tracks your usage against the line you paid for, interactive work and background work show up separately, which matters because of what we just covered. You can see the overnight jobs quietly stacking up, and you can see the daytime spikes from people clicking around. Then the overage view. This is where you see carry forward the debt as an actual number. You can watch it build after a heavy job and drain back down if it never drains. You're not having a bad day. You're undersized. And then the part I'd open first the top consumers broken down by item, not by workspace, by item. A single notebook, a single semantic model, a single pipeline. The report tells you which one burned the most units in the window you picked. That's useful because the question is never. Is the capacity busy? The question is who's eating the pool and who owns it. The app answers the first half. The second half is yours because the app gives you an item name and a workspace name. It doesn't hand you a person. You still have to walk over to the workspace, check the roles, and find the owner. And if nobody can tell you who owns it, that's your real finding. Not a capacity problem. An ownership problem. Now the limits. The app shows consumption. It doesn't tell you why something was expensive. A model that refreshes badly looks the same as a model that refreshes. Often you'll know the item is heavy. You won't know if the fix is a better query, a smaller schedule, or a bigger capacity. That conversation needs the data team. It also lags. It's not a live view. It's a report built from collected usage data. So by the time something shows up, the damage may already be a few minutes old, which is why alerts matter more than the dashboard itself. You can set up notifications on a capacity. When utilization crosses a threshold, you choose, say, eighty percent fabric emails, the people you name, capacity admins, a shared mailbox, whoever should hear about it. First. The goal is simple you hear about trouble before a user does. Right now, in most tenants, the order is reversed. A user hits an error, they open a ticket. You open the ticket, you ask the data team, and somebody finally goes looking at the pool. That's three handoffs to learn something a threshold could have told you an hour earlier. So set the alert. Pick a number lower than you think you need. Eighty is a decent start and you can tune it once you see how your capacity behaves. Now, an honest observation about this tool. Nobody reads this dashboard until something fails. It's the same story as a backup report or an audit log. It sits there full of answers and nobody opens it on a calm Tuesday. Then the capacity gets throttled. A leader asks what happened and suddenly everyone wants to see it. By then. You're reading it backwards. You're trying to reconstruct a cause from a symptom. The fix is boring. Put a short look at it on a weekly rhythm. Ten minutes. Check the trend. Check the top items. Check whether the debt drained. You're not hunting for problems. You're learning what normal looks like. So abnormal is obvious that baseline is what makes everything else in this episode manageable. Because once you can see the pool, you can start asking a harder question, not how to watch one capacity, but how many to have in the first place capacity design one pool or many? Start with the simplest question how many capacities should a tenant have? One is easy to run one bill, one dashboard, one alert, but one is also one blast radius. And we already know what that means. So most tenants end up splitting. The real decision is where to draw the lines. The first cut that earns its keep is environment development test production. Here's why. Developers experiment. They run big jobs, break things, and rerun them. That's their job. But if their experiments share a pool with the finance report, the CFO opens at nine. The CFO pays for it, put production on its own capacity, and a runaway notebook in dev can't slow it down. It can only slow other developers, which is a conversation you can have. Test sits in the middle. It can be small because it mostly runs checks before something moves to production. Many teams size it like dev and only scale it up for a release. Now the second cut, do you split by department or by type of work? Splitting by department feels natural. Finance gets one, marketing gets one, operations gets one. It maps to org charts. And it makes chargebacks simple because each bill has a name on it, but it has a flaw. Departments don't run the same kind of work. A team that does heavy overnight engineering and a team that mostly opens reports have very different shapes. Put them together and the pool serves neither well. Splitting by workload type fixes that heavy background engineering goes in one pool report, viewing an interactive work goes in another. People waiting on a screen never compete with a job running at two in the morning. The trade off is cost tracking. Now each bill covers several departments and you need another way to say who used what. That's where item level data from the metrics app comes back in. There's no perfect answer. Small tenants often start with environment, only larger ones layer workload type on top. What matters is that you choose on purpose rather than inheriting whatever the first trial created. And every choice carries a cost. Either way, isolation protects you from the noisy neighbor, but isolation also leaves capacity idle. A small dev pool sits at ten percent most of the day, and you pay for all of it. One big shared pool wastes less because someone else's quiet hour covers your busy one. Your trading waste for safety and the right balance depends on how much a slow report really costs your business. Now, one setting you can't change later without effort. Region. Every capacity lives in a specific Azure region. Your tenant has a home region and where you place capacities, decides where the data is processed and stored. For some organizations, that's a preference. For others, it's a legal requirement tied to data residency rules. So before anyone creates a capacity. Check the region, check it against your compliance obligations, and check where your tenant's home region sits. Because that's the default people will land on if nobody picks. It's also worth knowing that a workspace can only be assigned to a capacity the right way, and moving across regions isn't a button. Click get it wrong early and fixing it means moving data. Last piece. Pause and resume. FS queues can be paused when a capacity is paused. You stop paying for the compute. The data stays. Nothing is deleted, but nothing runs either. Reports won't load, refreshes won't fire. And anyone who tries gets an error for dev and test. That's a real saving. Pause them overnight and on weekends and the bill drops a lot. Some teams, even automated production is different. Pausing it takes the business offline and there's a catch when you pause a capacity, any outstanding carry forward debt gets billed right then as a lump. So pausing isn't always the free exit it looks like, which means the habit worth building is simple know which capacities can sleep and which can't. That covers the compute side, capacities, pools, regions, and how to cut them. But compute is only half the picture. The other half is where the data actually sits.

00:18:57 Speaker: One leg, one copy, one leg. Every tenant gets exactly one. One leg. You don't create it. You don't size it. You don't pick a storage account for it. It's there. The moment fabric is on and every workload in the platform reads from it and writes to it. That's the idea. One logical store for all three steps of the flow. Data arrives into it. Reasoning happens on top of it. Orchestration moves things in and out of it before fabric. Each of those steps tended to keep its own copy. The engineering team stored files one way. The warehouse team loaded them again into a database. The reporting team imported a third copy into a model. Same data, three places, three versions of the truth and three bills. One lake removes that one copy, and every engine reads it where it sits. What makes that possible is the format. Underneath one, Lake stores tables as Delta parquet. Parquet is an open file format. Delta adds a transaction log on top of it so you get reliable updates and history. Nothing in it is locked to Microsoft. Other tools can read those same files directly for you. That means two things. The data isn't hidden in some sealed box, and it isn't hard to get out either. Keep that second one in mind because we'll come back to it. Now, a structural comparison. You already know one drive, one tenant, one OneDrive service, and inside it a folder for every person. You don't set up a separate storage system per user. You just have folders in one place with permissions on each one. Lake works the same way one lake per tenant inside it, a folder for each workspace. Inside those folders for each item. Same shape, same logic of one place, many containers and that comparison also shows you the catch. When every team had its own storage, the walls came for free, finance kept its files and finances. Account marketing kept theirs somewhere else. You couldn't wander from one into the other because they were in different systems. One lake removes those walls. That's good for sharing because data doesn't need copying to be reused. A team can point at another team's table and use it where it sits. But the walls weren't just inconvenient. They were also protection. Quietly doing a job nobody wrote down. Take them away and the protection has to come from somewhere else. Permissions, roles, labels, all the layers we're about to walk through. So one copy is a real gain. Fewer duplicates, less drift, lower cost. It just moves the burden. You stop controlling data by controlling where it lives. You start controlling it by controlling who can reach it. That's a different job. So what should you as an admin actually care about here? Three things. Location. One leg data sits in the region of the capacity behind each workspace. Back in capacity design, I said region matters for residency. This is where that choice becomes physical. The files themselves live their access paths and this one is easy to miss. There's more than one way into the same data. Someone can open a report, someone can run a query through a warehouse, and someone can connect straight to the files using the same kind of path they'd use for any storage account. Through APIs and tools like Azure Storage Explorer, or one Lake File Explorer on their own laptop, each path can have its own rules. A person blocked on one route might not be blocked on another. If you only watch the front door, you won't see the side entrance. And third, who can see what not in theory. In practice, which people? Which groups? Which workspaces. Because with one leg a single wrong role doesn't expose one data set, it can expose a whole workspace of them. You also don't need to learn the file layout. Don't worry about folders of parquet. What you need is a clear picture of the boundaries drawn around those folders. And that's where the structure starts. Because inside the lake, the first and most important boundary isn't a table or a file, it's the workspace. Workspaces. The real unit of control. A workspace looks like a folder. It isn't in the portal. It's a box with a name where people put reports and notebooks and tables. But that box does four jobs at once and each one lands on your desk first. It's a container. Everything people build in fabric lives inside one. Nothing floats free. Second, it's a security boundary. Roles are assigned at the workspace level, and those roles decide who can see and change everything inside it. Third, it's a capacity assignment. Each workspace points at exactly one capacity, and that link decides which pool it draws from and which region its data sits in. And fourth, it's a deployment unit. Teams connect a workspace to git or move content through dev test and production with deployment pipelines. So the workspace is also where change happens one object container boundary compute link and release unit. That's why I call it the real unit of control. If you want to govern fabric, you govern workspaces. Now the roles there are four and the name sounds softer than they are. Admin can do everything. Add people, remove people, change settings, delete the workspace. Member can do most of that, including adding other people at or below their own level. That surprises people. A member can let more people in. Contributor can create, edit and delete content, but can't manage who has access. Viewer can look. That's the intent anyway. A viewer sees reports and read only content. Here's the trap. Most people treat viewer as the safe, default and contributor as the normal one, but roles don't care about intent. A contributor can write to the lake, which means they can put data in, change it, or remove it. And in some setups, higher roles can reach the underlying files directly, not just the reports on top. Viewer is the only role that reliably stays on the reading side. So when someone asks, can I just make them a member so it works? The honest answer is that you're handing out the ability to invite others. Now, the pattern that should feel familiar workspace sprawl is the new site sprawl. You've seen this movie teams made it easy to spin up a team, so people did. Hundreds of sites appeared, half had no owner, a quarter were empty. Nobody could say which ones mattered. Fabric is walking the same road, only faster because each workspace can hold real data and real compute cost. A forgotten SharePoint site is clutter. A forgotten workspace can keep refreshing a model every night. Burning units long after the person who built it has left. So every workspace needs three questions answered before it exists, ideally right after at worst. What is it called? Not test two or mix stuff. A name that says the team, the purpose and the environment. So you can tell a production sales workspace from a dev one without opening it. Who owns it? One named person or one group who can answer when something goes wrong. Not whoever created it. Whoever's accountable. And when does it end? Every workspace needs a lifecycle. A review date, a point where someone says keep it or retire it. Without that, nothing ever leaves. Naming ownership lifecycle. Three questions. If a workspace can't answer them, it's already drifting. And here's what makes this worth your time. These three answers cost almost nothing to ask on day one. Asked a year later across two hundred workspaces. They're a project. So decide the rules before the sprawl because after it you're doing archaeology. Now a workspace by itself is only the box. What matters next is what people put in it. And every one of those things carries the workspaces risk along with it. Items like houses, warehouses and semantic models. Everything inside a workspace is called an item. A lake house is an item. A warehouse is an item. So is a notebook, a pipeline, a report, a semantic model. Each one is a unit with a name, an owner, and a place in the flow we talked about earlier. You don't need to know how to build any of them. You need to know what each one means for governance. So let's go through the three that carry the most data. Start with the lake house. It's where files and tables sit together. In the lake itself, engineers drop raw files in, then shape them into delta tables. It's flexible and it's usually the first place data lands for you. That means it's often the least tidy. Raw exports, half finished tables, folders. Nobody named. Well then the warehouse. Same lake underneath, but a different experience on top. It looks and behaves like a traditional SQL database. Structured tables, strict schemas, permissions that feel familiar to anyone who's managed a database before. Warehouses tend to hold cleaner, more finished data. People trust them more, and that trust is exactly why they matter. And the semantic model. This one sits one level up. It's a layer of meaning built on top of data, relationships, calculations, definitions like what counts as revenue reports read from semantic models, not from raw tables. So when a leader looks at a number on a screen, a semantic model is usually what produced it. Three items raw, structured, and meaningful. They map neatly onto the flow. Data arrives in a lakehouse, gets shaped in a warehouse, and gets delivered through a semantic model. Now here's the rule that ties them together every item inherits its workspace's risk. A workspace rule applies to the items inside it. If someone is a contributor in a workspace, they're a contributor on the lakehouse, the warehouse, the model, and the pipeline. You can add narrower permissions on individual items, and we'll get to that. But the starting point is the workspace. So a workspace that mixes sensitive finance data with a casual experiment doesn't have to risk levels. It has one, the higher one. That's why mixing matters. Someone drops a test notebook into the production sales workspace because it was convenient. Now the notebooks author can read everything the workspace holds. Nobody decided that. It just followed from where the item landed. So the cleanest governance habit here is simple keep sensitive items in workspaces built for them with tight roles. Keep experiments somewhere else. One more question worth asking about any item. Does it create a copy or does it point some items? Copy data. A pipeline that loads a table into a warehouse makes a new set of files. A semantic model in import mode pulls a full snapshot into memory. Each copy is a new place. The data lives and a new place. It can drift out of date or out of policy. Other items only point. A shortcut in a lake house looks like a folder, but it references data stored somewhere else. A semantic model in direct lake mode reads the delta files in place without importing them. Nothing new is stored. This matters when someone asks where does this data actually live? If the answer is a copy, you have another thing to label, retain, and delete. If the answer is a pointer, the source still controls it. You won't catch this by looking at a workspace list. The item type tells you a lake house with shortcuts behaves very differently from one full of loaded tables, even when the two look identical in the portal. So when you review a workspace. Don't stop at the name. Look at the item types and ask which ones hold data and which ones. Just reach for it. That tells you how far the risk really spreads, and once you know what's in the box, the next question is who gets to switch things on in the first place, because that's decided somewhere else entirely in the tenant settings, tenant settings, the switchboard you didn't know you had. Tenant settings are where fabrics rules get written. You'll find them in the fabric admin portal under a page called Tenant Settings. It's one long list of switches grouped by area. Some are on, some are off. Some can be limited to specific groups, and almost nobody outside the data team has ever opened it. That's odd because this page decides a lot. Who can create things, who can share them, what can leave the tenant? If the capacity is the pool and the workspace is the boundary? This page is the switchboard behind both. Now, not every switch works the same way. There are two kinds, and the difference matters for who can touch what. Some settings apply to the whole tenant. One switch, one answer for every person and every capacity. Turn it off and it's off everywhere. Other settings can be delegated. A tenant admin can let capacity admins make their own choice for their own capacity, or let domain admins decide for the workspaces in their business areas, so the same setting can have a different answer in two places and both are valid. That's useful when you trust the people closer to the work. It's also how a tenant ends up with rules nobody can list from memory. If you don't know which settings you've delegated, you don't know your own policy, so find that out first. For each setting, ask whether it's set here or somewhere below. Then look at the big switches. A handful of them carry most of the weight. Who can create fabric items at all? This one decides whether the whole platform is available to everyone, or only to people you name who can create workspaces. Remember what we said about sprawl? This switch is where sprawl either starts or doesn't, and who can export data to Excel reports to files, tables to somewhere outside the service. Every export is a copy that leaves your controls behind. Each of those can be scoped. You can say everyone in the organization. You can say only these security groups, or you can say everyone except these groups. Those three choices produce very different tenants. Now here's the pattern. I'd ask you to check against your own defaults. Favor adoption over control. That's not a criticism. It's a design choice. Microsoft wants people to try fabric and succeed. So many settings arrive. Open. Sharing is on. Creation is broad. Exports are allowed. The platform assumes you'd rather say yes first and tighten later. The problem is the later. Because tightening a setting after people depend on it means breaking something they built. A rule you set before launch is a policy. The same rule set a year in is an incident, and what typically happens is simple. The settings stay on defaults for a year. Nobody decides that. It just happens. The data team has what it needs. The admins have other fires. Nothing breaks, so nothing gets reviewed. Then an audit arrives or a sensitive data set turns up in a workspace nobody expected, and someone opens the settings page for the first time. Everything is exactly as Microsoft shipped it, which tells you something about the model most tenants run on. They assume the platform is configured because it works. Working isn't the same as configured. There's one more detail worth knowing before we go through the specific switches. Changes to these settings aren't instant everywhere. Some take effect within minutes, others can take up to an hour, and not every setting is applied the same way to people who are already signed in. So when you change something, don't test it 30s later and decide it failed. Also, write down what you change. The portal doesn't give you a clean before and after view. If you toggle three settings on a Tuesday and a user complains on Thursday, your memory is the only record. A simple log, even a shared node, saves you a long afternoon. So treat this page like you'd treat a conditional access policy. Review it on a schedule, change it on purpose. Record why. And since the list is long, you don't need all of it at once. A few settings do most of the work. Those are the ones worth a closer look. There's the settings that matter most. Start with the first switch where the fabric is on at all. The setting is called. Users can create fabric items two modes. You can enable it for the whole tenant or for specific security groups. Most tenants pick the first because it's the default and nobody asks. Pick the second. Create a group. Call it something plain like fabric creators put the data team in it, plus a few pilot users. Now the platform is available to people who've been named and everyone else sees nothing new. When the business wants to widen access, you add people to the group. That's a change you can track instead of a switch. Nobody remembers flipping. Next export and sharing this cluster matters most for data leaving your control. Look at the export options first. Export to Excel. Export to CSV export. With Live connections. Each one produces a file that sits outside fabric with no label enforcement. Unless you've set that up and no way for you to pull it back. You don't have to turn them all off. Scope them, allow them for the groups who need them, and block them where the data is sensitive. Then external sharing. There are settings that let people share content with guest users outside your organization. Some let guests see reports, some let them edit. Think about who in your tenant should be able to invite an outsider into a data workspace. And the honest answer is usually a short list. And then the one with the scariest name publish to web. It creates a public link to a report. Anyone on the internet who has that link can open it with no sign in, no identity check, no conditional access, nothing. If a report holds anything internal, this setting turns it into public content with one click. Most organizations should have it off. If someone has a real reason, scope it to a small approval group and review that list often. Now, automation two settings control whether code can talk to fabric without a person behind it. One let service principles use fabric APIs. The other lets them work with the admin APIs. A service principle is an app identity. The kind of pipeline or a script uses. These are normal and useful, but they also mean something that isn't a human can read and change tenant data, so don't enable them for everyone. Enable them for a specific security group and put only the approved apps in it. If you can't name every identity in that group, the setting is too open. Then there's the part that's moving fastest copilot and preview features. Copilot and fabric has its own tenant setting, and so do many of the previews. Preview features arrive on a schedule that has nothing to do with your review cycle. One morning, a new option appears often on by default or easy to enable, and it touches data in ways your last review never considered. So treat these two the same way. Decide who can use them. Scope the setting to a group and check the list of preview toggles on a regular rhythm. Because the list grows, will come back to copilot properly in a later section. For now, just know the switch exists and the default may not be the one you'd have chosen. Now let me make this practical. Here's a short list you can run on Monday morning, open the fabric admin portal, then tenant settings one find users can create fabric items, change it from the whole tenant to a named security group. Two find publish to web, turn it off or limit it to a small approved group three review every export setting, ask which ones the business truly needs and scope the rest. Four check the external sharing settings. Know who can invite guests and who can't. Five find the service principal settings if they are open to the whole organization, move them to a group six. Look at copilot and the preview toggles and note which ones are on, and seven for every setting you touch, write down what it was, what you changed it to and why. That's about an hour of work. It won't finish your governance, but it moves you from everything is as Microsoft shipped it to. Everything is a decision someone made. Now all of these switches answer one kind of question who is allowed to do what? But they all depend on something earlier. Before a setting can apply to anyone, that person has to get in, and that's decided by identity. Identity entry ID as the front door fabric doesn't have its own user directory. Every sign in goes through entry ID, same accounts, same groups, same tenant you already run. Nobody creates a separate login for fabric and nobody could if they tried. That's good news. And it's easy to overlook because it means the work you've already done carries over your conditional access. Policies apply to fabric the way they apply to anything else behind entra. Require a compliant device, and fabric asks for one block silence from certain countries, and fabric blocks them to demand multi-factor authentication, and it's there at the door. So before you build anything new, check what you already have. Open your conditional access policies and look at the cloud apps they cover. If a policy targets all cloud apps, fabric is already inside it. If you scoped policies to specific apps, fabric may be sitting outside them because it shows up under the power BI service and related Microsoft services rather than as one obvious name, that gap is worth ten minutes of your time. Now, guests enter a B2B lets you invite people from outside your organization, and fabric accepts them like any other identity a partner, a contractor, a consultant on a six month project. Once they're a guest in your directory, someone can add them to a workspace, and that's the part to watch. The guest invitation happens in enter. The access decision happens in fabric two different places, usually handled by two different teams. A guest added as a workspace contributor can touch the same data your own staff can not just reports the lake underneath. And if the sharing settings we covered a moment ago allow it, a guest can invite more guests. So ask who's allowed to bring outsiders in, and whether you'd know if they did. The cleanest control here is boring. Treat guest access to fabric like any other guest access. Same expiry. Same access reviews, same sponsor who vouches for them. If you already run access reviews on teams and SharePoint, add the fabric groups to the list, which leads to the habit that matters most. Assign roles to security groups, not to people. When you add a person directly to a workspace that grant lives in one place and nowhere else, it doesn't follow them. When they change teams, it doesn't disappear. When their project ends, it just sits there quietly until someone audits it. When you assign a group instead, the access follows the group. Someone leaves the finance team, they drop out of the finance group and their fabric access goes with it. One change in entry and every workspace that group touches is updated. That's how you keep one hundred workspaces honest without opening one hundred roll lists. Name the group so they explain themselves. Team workspace role. Then the group name tells you what it does and the membership tells you who has it. Automation works the same way with different identities. Pipelines and scripts shouldn't run as a person's account. Use a service principle or a managed identity where it fits. A person's password can expire, their account can be disabled, and then something critical breaks on a Saturday. An app identity has no such life events. It also has a clean owner and a clean audit trail. And here's the flaw I see most often teams grant roles to individuals and never go back. A developer needs access for a launch, so someone adds them as a member. The launch ends, the developer moves on. Eighteen months later, they still have that role in a workspace holding data they'd have no reason to see today. Nothing flagged it because nothing was designed to. That's not an entry failure. It's a missing review. So identity gets people through the door and with the right setup, it also takes them out again. But getting in is only the first check. Once someone's inside, fabric asks a different set of questions at every layer.

00:38:11 Speaker: The fabric security model in layers. Security and fabric isn't one lock, it's five stacked. Each one asks its own question. Layer one is the tenant. Can this person use fabric at all? That's the settings we just covered. Plus, identity layer two is the capacity. Can this person's work land on a pool capacity? Admins and contributors decide who can assign workspaces to it. Layer three is the workspace. What role does this person hold inside the box? Layer four is the item. Does this person have a direct permission on one report, one Lakehouse, one model and layer five is the data itself. Which rows, which columns? Which tables can they actually read? Here's why that matters. A person can pass at one layer and fail at the next. Someone can be a viewer in a workspace and still see no data, because a rule further down blocks them. Another person can have no workspace role at all and still open one report because someone shared that single item with them directly. So does Sam have access? Isn't a yes or no question. It's a question you ask five times now. The part that trips people up some permissions stack and some override stacking is the common case, a workspace role and an item permission add together. Give someone viewer on the workspace, then share one report with edit rights and they get both the more generous grant wins for that item. Overriding is rarer and it comes from the data layer. Row level security, for example, can narrow what a person sees even when their role would otherwise show everything. We'll get into that next, and some roles skip the narrowing entirely. Admins, members, and contributors are usually exempt from those data rules inside the workspace because their role lets them reach the underlying data directly. That exemption is easy to forget. You build a careful rule at the bottom, and then you hand out a role at the top that walks around it. Let me make this concrete with one example. A sales report called Quarterly pipeline. Start at the tenant. Priya works in sales. She's in the fabric creators group. So fabric is open to her past capacity. The sales workspace sits on a production capacity. Priya doesn't need anything there because she's not assigning workspaces pass and it doesn't matter. Workspace. She's a viewer through the sales readers group. She can open reports, but she can't edit or see the notebooks that feed them pass with limits. Item. Nobody shared quarterly Pipeline with her directly, but her viewer role already covers it. Pass data. The semantic model has a row level rule that limits each rep to their own region. Priya sees only the Western accounts. That's the layer doing its job. Five checks, one person, one narrow view. And each layer could have been the one that said no. Now flip it. Imagine Priya got moved to contributor so she could fix a chart. Same report, same rule at the bottom. But now her role can reach the model's data directly and the regional limit no longer protects anything. One change at layer three quietly undid layer five. That's where mistakes usually hide. The first one is the workspace role. That's too broad. Someone needed to do one thing, so they got member and member does naughty things. The second is the forgotten item. Permission. A report shared with an individual for a deadline never removed. Still working. A year later, after the workspace roles were cleaned up. Everything looks tidy at the top. The old grant sits underneath. So when you review access, don't read just one layer walk down tenant capacity workspace item data. Ask what each one allows and whether the next one narrows it or contradicts it. You'll also find that most problems sit in the middle two layers. The tenant is usually reviewed. The data rules are usually somebody careful work. It's the workspace and item permissions the ones granted in a hurry. That drift. Which brings us to the deepest layer where the rules stop describing who can enter and start describing what they can see. Row level. Column level and one leg. Security. This is the layer where the rules stop describing who gets in and start describing what they see. Start with row level security. It filters rows. Two people open the same report and each sees only the rows. The rule allows. A sales rep sees their own region. A manager sees their whole team. In fabric, you'll find it in two places. In a semantic model where someone defines a role with a filter and assigns people to it. And in a warehouse where the same idea runs through SQL using a predicate that the database applies on every query. Same goal. Different engines. Different people building it. Now column level security. This one hides columns instead of rows. A salary field, a national ID, a personal email address. The person can query the table, but the sensitive column comes back blocked or doesn't appear at all. It lives mostly in the warehouse and SQL endpoint set, with the same kind of grant and deny statements. A database admin already knows. Then object level security, which is the blunt version. It hides a whole table or a whole column in a model so the person doesn't even know it exists. So three tools, rows, columns, objects. Each one narrows the view. But all three have a shared weakness, and it's the one I'd want you to leave with. They protect the layer where they were built, nothing more. A rule set in a semantic model protects people who read through that model. It does nothing for the delta files underneath. If someone has a workspace role that reaches the lake, they can open those files directly with no model in between and no filter applies. The careful regional rule sits on a door that nobody is forced to use. That's the trap. The security looks complete in the place where you checked. It isn't complete in the place where the data actually sits. And this is why one lake security exists. One lake security lets you define access roles on the lake itself. You pick a lake house, choose which tables or folders a role can read, and assign people or groups to it. You can add row and column rules at that level two the rule lives with the data, so it applies to the SQL endpoint to spark to direct lake models to anyone reaching those files by any route that changes the access path story before each engine enforced its own rules. And you had to trust that every route had been covered with one leg security. The lake becomes the place, the rules are checked and the engines respect them. It's still a newer feature and it has conditions. People who hold higher workspace roles can bypass it for the same reason we saw before. Those roles reach the data directly, so the workspace role still matters. A tight lake rule is only as strong as the roles above it. That leaves you with a short set of questions. You won't build these rules, but you can ask the people who do. Where is the row or column rule defined in the model, in the warehouse, or in the lake? Can anyone reach the same data without going through that layer? If the answer is yes, how? Who holds admin, member, or contributor in this workspace and do they need the access those roles carry? And is anyone relying on a model rule to protect a lake house that people can open directly? That last one is the question most owners haven't asked. They built a clean rule, tested it in the report, and called it done. They never tried the side entrance. So when a data owner tells you the data is secured, don't argue. Just ask where, because the answer tells you which layer is carrying the weight and whether the others are standing behind it. Now, even a well-built rule can only protect data that someone knows is sensitive, and knowing that depends on whether anyone marked it. That's the job of labels. And in Microsoft, three hundred sixty five, labels come from purview, sensitivity labels and purview integration. You already have sensitivity labels. You built them for word files and emails and teams. The good news fabric reads the same ones. Same label names, same taxonomy, same purview. Admin center. Nobody builds a second set for the data platform if your tenant has confidential and highly confidential. Those are the labels a report or a lakehouse can carry. First, an admin has to switch it on. There's a tenant setting that lets fabric use sensitivity labels, and another that controls who can apply or change them. Both live in the same switchboard we just walked through. If they're off, the labels exist in purview and nothing in fabric can touch them. Now, the part that makes labels more than a sticker inheritance, say a lakehouse table, carries highly confidential. a semantic model reads. From it. A report sits on that model when labeling flows the way it's meant to. The label travels downstream. The model picks it up, the report picks it up. And when someone exports that report to Excel or PowerPoint, the file leaves with the label still attached, including any encryption and access limits you set on it. That's the point where labels start to matter for you. A person who exports a labelled report can't quietly email the file to an outsider because the label travels with it and the protection rules come along. But inheritance has limits, and they're worth knowing. It follows the direction of the data. It doesn't work backwards. A report labelled confidential doesn't make the lake house upstream confidential, and there are cases where a downstream item gets its label only if nobody has already set a different one by hand, a manual choice can override what flows in. Then there's data loss prevention purview. DLP policies can now cover fabric with a narrower reach than you might hope. Today, they focus on semantic models. You can write a rule that says if a model holds a sensitive information type, such as credit card numbers or national IDs, then alert the owner, notify the security team or restrict access to the model. It scans the content, not just the label, so it catches data that nobody marked. That's a real gap closer, but treat it as one control, not full coverage. Lake houses, warehouses, and pipelines aren't all covered the same way, and the list of supported items keeps changing. Check the current documentation against what your data team actually builds. Next, auditing fabric activity flows into the same purview audit trail as everything else you track in Microsoft three. Sixty five who viewed a report? Who exported it? Who changed a label or removed one or all of it lands in one place, searchable with the tools your security team already knows. So when someone asks whether a person downloaded the quarterly numbers, you don't need a fabric specific investigation. You search the audit log the way you'd search for a SharePoint file. Now the catch. And it's the oldest catch in data governance. Labels work only when someone assigned them in the first place. Think about what has to happen. An engineer loads a table, a model gets built, a report goes out. At no point does any of that force a person to stop and classify the data. If nobody labels the source, there's nothing to inherit. The whole chain carries no label, and every control that depends on one stays silent. This is how a tenant ends up with beautiful labeling policies and a lake full of unlabeled data. The policy was never the problem. The labeling just never happened. You have a few ways to close that. Set a default label so new items start protected instead of blank. Mark labeling as mandatory in your label policy. So people must choose before they can save and use Purviews scanning to find sensitive content in data sources and apply labels automatically where that's supported. None of those are perfect. Each one trades convenience for coverage, but a default label that's slightly too strict beats a lake where nothing is marked at all. So labels give you a way to describe the data. Purview gives you a way to track it, and both depend on people and process. Not just a setting, but labels describe risk. They don't describe meaning for that. Fabric adds one more layer and it's organized around the business, not the tenant. Domains. Endorsement and data discovery labels. Describe risk domains. Describe ownership. A domain is a grouping of workspaces by business area, sales, finance, supply chain, HR. You create it in the admin portal, assign workspaces to it, and the workspace is now carry a business name that means something to people outside it. That sounds cosmetic. It isn't, because domains also let you hand out control. You can name domain admins, people from the business who manage their own area. They can decide which workspaces belong, and they can override certain tenant settings for their domain. If you've delegated those. So the finance lead can set finances rules and you don't have to approve every change. And this is where the model shifts. Before you thought in servers and sites, someone owned the box. Now the question is who owns the data product, meaning the finished usable thing a team publishes for others to rely on. A domain gives that owner a home. Next endorsement. This one is about trust. Any item can carry one of two badges. Promoted means the owner says this is good and they'd like others to use it. Anyone with write access can do it. Certified is stricter. A person you've authorized has to review the item against your standards and stamp it. Only specific people or groups can do that, and you pick who treat that list like a short keyring. So the badge isn't decoration. It's a signal when someone searches for a sales model and find six. The certified one tells them which to believe, but a certification is only worth what the review behind it is worth. If anyone can certify, or if nobody checks what they certified last year, the badge becomes noise. Decide what certified means in your tenant. Write it in three lines and keep the certifier list small. Now. Discovery fabric has the one leg catalog, a single place where people browse and search the items they can see. Filter by domain. By item. Type by endorsement. By owner. It's built so someone can find a trusted data set without asking around. Two details matter to you. The catalog shows items based on what each person can access, so it doesn't open any doors on its own, and it surfaces metadata like names, owners descriptions, and labels, which means those fields are suddenly worth filling in. An item called final v2 copy with no description is invisible to anyone who needs it. Here's the problem, though discovery without governance creates a different kind of failure. If finding data gets easy and nothing says which data is reliable, people grab whatever turns up first. Two teams find two versions of revenue. Both look official. Both are wrong in different ways. Nobody breaks a rule because no rule existed, and the damage is that people stop trusting the numbers at all. Trust problems cost more than access problems because they're quiet. Nobody files a ticket saying they no longer believe the dashboard. They just built their own spreadsheet. So the pieces work as a set. Domains say who owns it? Endorsement says whether it's trusted. The catalog says where it is. Take away one and the other two get weaker. For you, that means a small set of decisions which domains exist and who runs each, who may certify, and what a workspace must fill in before it appears in the catalog. Those decisions are about people and accountability, not about compute. And that points to the last piece of governance, the one every finance team asks about first. What does each person and each team actually pay for licensing basics? What you actually buy. Fabric licensing splits into two parts. Most confusion comes from mixing them up. One part buys compute, the other part buys people. The compute side is the capacity. You buy an F SKU and it gives you your workspaces, a pool of capacity units to run on. And we covered what that pool does. What matters here is that this purchase belongs to the organization, not to any one user. Nobody holds a personal license for it. The people side is the per user license, and this is the one that surprises M365 admins because it's the power BI model you may already know. Here's how the three pieces fit. Power BI Pro is a per user license. It lets a person create and share content in workspaces and in the classic setup, it also lets them view shared content. Premium per user or PW is a step above it. It adds the larger model and premium features, but it's still tied to the individual, and PW content can only be shared with other PW users. Then the F SKUs. These are the capacity side sized from F2 up to F2 forty eight, each step doubling the one before they are built by the capacity, not by the head. Now, the question every admin gets asked who needs a license to view and who needs one to create? It depends on the size of the capacity behind the workspace. On a smaller F SKU below f sixty four, viewers still need a pro license to open power BI content. The capacity pays for the compute, but the person reading the report needs their own license at sixty four and above. That changes. Viewers of power BI content don't need a paid license as long as the workspace sits on that capacity. A free license is enough to read. Creators still need Pro or PW to build and publish. That Ef64 line is the number to remember. It's the point where licensing flips from everyone pays to only builders pay. And for a company with thousands of readers and a few dozen authors, the flip is the whole business case. One caution that viewing rule is about power BI content. Other fabric items follow their own rules. Someone working in a lake house or a notebook doesn't need Pro just to be there, but they do need a workspace role and a capacity that's running. So don't hand one sentence to a manager and call it settled. Check the item type. Now the trial. It's worth a few words because it's how most tenants meet fabric. A trial gives a user a trial capacity sized roughly like an F sixty four for a limited number of days. It's generous and it's meant to be. Teams build real things on it. Real pipelines, real models, real reports that other people start using. Then the trial ends. When it does, there's a grace period, and after that the workspace is on that capacity. Stop working. Items aren't deleted right away, but they aren't usable either. So the thing someone built to prove a point turns into an outage if nobody moved it to a paid capacity first. That's why I treat every trial as a deadline with a date on it, not a free sandbox. You can also control who starts a trial. There's a tenant setting for it. If you've scoped fabric to a creator's group, scope the trial the same way or people will route around you. And the last piece is how the capacity itself gets paid for. Pay as you go is the simple one. You turn a capacity on your build per second while it runs, and you can pause it so the billing stops. It's flexible and it costs more per hour. Reserved is a commitment. You agree to a one year term for a given size, and the hourly rate drops noticeably. The trade is that you pay whether you use it or not. At a high level. The pattern most teams settle into is straightforward start pay as you go. While the workload is unknown. Watch the usage for a few months, then reserve the baseline you're sure you'll keep and leave the spikes on. Pay as you go. Notice what's happened. Licensing isn't a purchasing detail. It decides how many people can read, who can build, and what happens when a trial runs out. And once you've chosen those options, the next question is how you keep the bill from drifting. That's a cost problem, and it starts with what you leave switched on cost control and chargeback a capacity bills for the time it's on, not for the work it does. Read that again, because it's the whole cost problem. A capacity sitting idle on a Sunday night costs the same per hour as one running a heavy refresh. The meter follows the switch and nobody feels it until the invoice lands. So the first lever is. Pause and resume an f s q on pay as you go can be paused and billing stops. Resume it and billing starts again for a dev or test capacity that people use between nine and six. That's a big difference. Pause it at night and you've cut a large slice of the bill without touching a single report. There's a catch worth knowing while a capacity is paused, the content on it isn't available. Reports don't open, refreshes don't run. So pausing works for environments where downtime is fine and it's the wrong move for anything a team relies on. At two in the morning, production stays on. Everything else gets a schedule. The second lever is size. You can scale an F skew up or down, and it takes effect quickly. So a capacity that needs to be large for a month end close doesn't have to stay large for the other twenty five days. Scale up when the load arrives, scale back when it leaves a script or an automation can do both, which means nobody has to remember. And here's what I'd ask you to notice. Both levers depend on someone knowing the capacity exists. That's the real failure behind most surprise bills. What typically happens is a forgotten dev capacity. Someone spun it up for a proof of concept, sized it generously, and moved on to the next project. It kept running month after month. It quietly built for compute. Nobody used because nobody owned it and nobody was looking. The first surprise bill usually isn't about growth, it's about something left on. So the fix is ownership and that leads to chargeback. You don't need a sophisticated system. You need a simple map. Every capacity has a cost owner, a name, person or team who accepts the bill. Every workspace points at a capacity, and every workspace belongs to a department, which you can track through the domain we covered earlier or through a plain naming rule. Put those three together and you can answer the question. Finance will ask who's paying for this capacity. Cost splits across the workspaces on it and workspaces roll up to departments. It won't be exact to the cent. It doesn't need to be. Tags help. Here in Azure, you can tag the capacity resource itself with a cost center and an owner, and those tags show up in cost reports. Set the tagging rule once, require it when a capacity is created and the billing data explains itself. Then there's forecasting. Don't guess. The capacity metrics app we looked at earlier already shows you how much of the pool each workspace consumed. Use that history. If a department used about a fifth of a capacity for three months, that's a number you can defend. And it's far better than an estimate someone made in a meeting. It also tells you when to change plans if utilization stays low, scale down, if it stays high and overages keep appearing, that's evidence for a bigger size or a reserved baseline, and finance will accept evidence faster than a request. Which brings me to the rules. Keep them few, because finance will only adopt what fits on one page. Every capacity has a named cost owner. Every non-production capacity has a pause schedule. Every capacity carries a cost center tag, and every month someone reviews utilization against the bill for rules. None of them need a new tool. But all of this still treats fabric as a thing on its own. Your tenant has another kind of data, the kind you manage every day, and sooner or later somebody wants it in the lake.

00:57:09 Speaker: How fabric connects to Microsoft three hundred sixty five data fabric doesn't contain your Microsoft three hundred sixty five data. Not automatically. Not by default, your mailboxes stay in exchange, your files stay in SharePoint and OneDrive. Your chats stay in teams. Turning on fabric doesn't move any of it, and nothing flows in until someone builds the connection on purpose. That's the honest starting point, and it's worth saying out loud because people assume otherwise. They hear one platform and picture all of Microsoft three hundred sixty five already sitting in the lake. It isn't. The lake starts empty of your collaboration data, and every piece that ends up there arrived because a person chose to bring it. So the real question is how it arrives. There's a set of connectors. Fabric can read from SharePoint lists and files from OneDrive, from Exchange and Teams, data through Microsoft Graph and from intra for identity and directory information. Data pipelines and data flows. Use them to pull content in on a schedule. A person with a creator role and the right sign in can set one up in an afternoon. Notice what that means. The permission to connect doesn't come from you. It comes from the account. The connector runs as if that account can read a SharePoint site. The pipeline can read it. If the account is an admin, the pipeline reads a lot. Then there's the heavy root. Microsoft Graph has two ways in standard graph calls fetch data in small pieces. A user here, a message there. They're fine for lookups. For bulk, there's graph Data Connect, which extracts large data sets from Microsoft three hundred sixty five into Azure storage for analysis, will give that one its own section because it moves a different class of data before that one distinction changes your whole compliance story. Shortcuts versus copies. A copy is what it sounds like. A pipeline reads the source and writes a new set of files into the lakehouse. Now two versions exist the original in Microsoft three hundred sixty five, governed by your retention and your labels, and the duplicate in the lake governed by whatever someone configured, which is often nothing a shortcut doesn't duplicate. It's a pointer. The lakehouse shows a folder, and the data stays at the source. For some storage targets. That works well, but for most Microsoft three hundred sixty five content, the practical route today is still extraction, which means copying. So when someone says we connected SharePoint to fabric, ask which one they did The answer tells you whether you have one thing to govern or two copies. Carry a quiet problem. Someone deletes a file in SharePoint because retention says to the copy and the lake doesn't know it keeps the file, the labels may not have followed, and the permissions that protected the original are gone. The lake has its own access model, and it was never told about the old one. What typically happens is a request that sounds harmless. Someone in HR, or it wants to understand email patterns, or find out which teams share the most files. A quick analysis so they pull a mailbox data set into a lake house, build a few charts, and present the result. The charts are fine. The data set stays behind sitting in a workspace with whatever roles it happened to have, holding message, metadata, and sometimes more. Nobody planned that as a data store. It became one because the files were still there. That's the risk to keep in view. Microsoft three hundred sixty five governance was built around Microsoft three hundred sixty five locations. The moment content leaves for a lake house, it leaves that governance behind unless you've carried the controls across by design. So for every connector in your tenant, you want three answers who built it? What account does it run as, and does it copy or does it point? Those three answers cover most of the risk and one connector. The bulk extraction route deserves to be treated apart because of how much it can carry in a single run. Graph data connect and bulk M365 data. Graph Data connect is built for volume. Standard graph calls work like a lookup. You ask for one user, one calendar, one folder and you get a small answer. Back graph data connect works like an export. You tell it which data sets you want for which users, and it delivers the whole set into Azure storage in one scheduled run. Mailbox. Metadata. Calendar data teams activity. SharePoint and OneDrive information thousands or millions of records at a time in a form made for analytics. From there, it can feed a lake house, and that's the path most fabric projects take when they want organization wide patterns instead of single answers. Now here's what you should like about it. It doesn't open the way a normal connector does. A person can't just click it on. There's an approval flow and it has several gates. First, someone needs an Azure subscription to receive the data because the extraction lands in Azure storage account that you control. Second, the app that pulls the data has to be registered in entra. Third, and this is the one that matters for you, a Microsoft three hundred sixty five admin has to approve each request. That's the admin consent step. Someone with the right role sees exactly which data sets the app wants, and which users or groups are in scope, and then says yes or no. Until that happens, nothing moves for the first approval. There's also a second approval, so one person can't wave it through alone. So this is one of the few places where the tenant admin is already a required signature. Take that seriously. The consent screen is the only point where you see the full ask in one place before any data exists. Read it like a contract. Which data sets which users for how long. A request for all users. All mail metadata is a very different thing from the sales group. Calendar events for ninety days. Push for the narrow version, scope by group, by data set, and by time range, and refuse anything the requester can't explain in a sentence. Now, why does bulk m365 data count as a different risk class? Because of what it is once it lands? Mail metadata shows who writes to whom, how often and when calendar data shows who meets with whom. Teams data shows who talks to whom. None of those need message bodies to be sensitive. Taken together across an organization, they describe how people actually work and who has influence and who is isolated. That's the kind of data set a works council cares about, and a privacy officer and a regulator. And it concentrates in Microsoft three hundred sixty five. That information is scattered across services, each with its own access controls in a lake. It sits in a few tables, readable by anyone with the right workspace role. You've turned a spread out risk into one file path. Then comes the problem. Nobody plans for retention and deletion. Suppose someone leaves the company and asks for their personal data to be erased. In Microsoft three hundred sixty five, you know how to do that. You find the mailbox, the OneDrive, the teams content, but a graph data connect extract from last spring already copied their activity into the lake, maybe into several tables, maybe into a downstream model and a report built on that model. The right to be forgotten doesn't stop at the Microsoft three. Sixty five boundary. It follows the data. And if no one recorded where the extract went, you can't honor the request because you can't find the copies. So decide a few things before the first extraction runs. How long does the data live in the lake? Who deletes it? And on what trigger is the data pseudonymized on the way in? So individuals aren't identifiable by default? And where's the record of every extraction with an owner's name beside it? Those answers are cheap before the data exists. After it does, they become a forensic project. That's the heavy route, and it needs heavy controls. The lighter connection, the one most teams reach for first works differently because it doesn't extract files at all. It points at them SharePoint, OneDrive, and shortcuts. A shortcut is a pointer. You create one inside a lake house. You aim it at a location somewhere else, a folder appears, open it, and the files look like they live in the lake. They don't. The bytes stay where they were. Fabric reads them on request. One lake supports shortcuts to other places inside fabric. It also supports outside storage like Azure Data Lake Storage, Amazon S3, and Google Cloud Storage. That's the list worth remembering. SharePoint and OneDrive aren't on it as plain storage targets for files, and those. The working route is usually a connector, a data flow, or a pipeline that reads the content and writes it into the lake so the word shortcut gets used loosely in meetings. You should ask what was actually built. Now what does a shortcut inherit? This part is easy to get wrong. When the target is outside fabric, the shortcut authenticates with a credential someone chose when they created it, maybe their own account, maybe a service principle. From then on, anyone who can read that shortcut in the lake house reads the external data as that credential, not as themselves as the identity behind the link. So if a person with broad storage rights builds a shortcut, a much wider group may end up seeing data they could never have opened directly. And that's delegated access. And it's quiet. Nothing prompts you when it happens. Then there's SharePoint as a source. Lists and files can feed fabric through connectors. A list becomes a table. A document library becomes a set of files or a table of file details. Business teams like this because so much of their working data already sits in SharePoint, in lists and spreadsheets, nobody ever moved to a database. And here's where the model gets split. In SharePoint, a file has permissions, site members a sharing link. A group may be a unique grant on one folder. Those rules took years to build and people understand them. In the lake house, the same file is now governed by workspace roles, item permissions and perhaps one lake security, a completely different system written by different people describing the same content. So ask a simple question who can read this file in SharePoint and who can read it in the lake house? Don't assume the answers match. Usually they don't take a document library with a restricted subfolder. Only the legal team can open it. A pipeline running under a service account that can see the whole library copies everything. Now the lake house holds the restricted files and every viewer of that workspace can reach them. SharePoint never told the lake about the restriction because the lake never asked. The same thing happens in the other direction. More slowly, someone gets removed from the site. Their SharePoint access ends that afternoon. Their workspace role stays because nothing connects. The two lists two permission models, one file, and no process keeping them in agreement. That's the trap. Not that anyone broke a rule, but that the rules were never joined. What can you do? Three habits first require that pipelines reading SharePoint run under a named service identity with access scoped to the sites it needs and nothing wider. Second, treat any workspace that holds copied SharePoint content as having the sensitivity of the most restricted thing inside it and label it that way. Third, when a copy lands in the lake, record which site it came from so someone can trace it back when the source permissions change. Notice that none of those fixed the split, they just make it visible and visible is better than silent. Now files and mailboxes are one side of your tenant. There's another side that's been growing faster, and it's the one most m365 admins get asked about. First copilot, copilot, data agents and the fabric connection fabric has its own copilot. It's separate from the Microsoft three hundred sixty five copilot. Your users already know it lives inside fabric. It helps people write SQL, build notebooks, generate Dax, and ask questions about a report in plain language. Different product. Different license path. Different switch, but the same name on the button. So people assume it's one thing. Let's start with the switch because you control it. There's a tenant setting in the fabric admin portal that turns copilot on for the tenant. You can scope it to specific security groups the same way you scoped fabric itself. And there's a related setting for data that gets processed outside your geography, because copilot requests can be handled by Azure Open AI in a different region than your capacity. If you have residency commitments, that setting needs a decision, not a default. Then the capacity requirement, copilot and fabric runs on paid capacity, not trial and not the smallest sizes. The requirement has moved over time, so check the current documentation rather than trusting a number from me. But the point holds every copilot request draws from the same pool as everything else. A prompt to write a query is background compute built like any other work. So a team that loves copilot is also a team that's spending capacity units. You'll see that in the metrics app under items nobody thought to plan for. Now data agents. These are the newer piece. A data agent is a configured assistant that answers questions over specific data. Someone points it at a lake house, a warehouse or a semantic model, adds instructions and publishes it. Then people ask it things in plain language and it writes the queries, runs them, and returns an answer. It can also be connected out to other tools, including copilot Studio and Microsoft. Three. Sixty five copilot. So what can an agent read? Whatever the person asking can read. That's the design and it's the right one. The agent runs with the identity of the user. So the same way as we walked through apply workspace role item permission row and column rules where they exist. If Priya asks about the pipeline, she gets the Western accounts because that's what the data layer allows for her. But notice what that puts on you. The agent doesn't add protection. It inherits whatever protection exists. If a lakehouse has a broad workspace role and no lake level rules, the agent answers from everything that role can reach. It's fast, it's friendly, and it has no judgment about what looks sensitive. That's the shift. Before a week, permission sat quietly until someone happened to browse to it. Now a person can type which employees were flagged last quarter and get an answer in seconds. The agent doesn't create the exposure. It removes the effort that used to hide it. So governance of the lake becomes governance of the answer. Think about what that means for the problems we've already covered. An unlabeled table is unlabeled in the answer A copied SharePoint library with flattened permissions is now searchable by sentence. A forgotten workspace role, the one that survived the project, is now a way in for questions nobody planned for, which is why context comes first. Before anyone builds an agent, ask what data it reaches and whether that data was ever meant to be read this easily. AI is only as safe as the data it can touch. Here's a short check you can run which tenant settings allow copilot and agents, and for which groups, which agents exist and who publish them. What data does each one reach and have those sources been through the access review we talked about for questions. And most tenants can't answer the second one yet because agents are items and items have owners and owners move on. That's the same life cycle problem again in a new place. And when something does go wrong with one, the first thing you'll need isn't a policy. It's a record of what happened. Auditing logs and admin monitoring fabric records a lot. The problem is it records in three different places. Each one answers a different question. Start with the monitoring workspace. It lives inside the fabric admin portal. It's built for admins, and it holds two reports Microsoft maintains for you. One covers usage across the tenant, the other covers feature adoption. You open it and you can see which workspaces are active, which items get used, and who's creating what. That's the quickest way to answer a simple question what's actually going on in our tenant? It won't tell you who did something wrong. It tells you where the activity is, and that's usually where you should look first. The second place is the activity log. Every meaningful action in fabric produces an event. Someone opens a report. Someone exports one. Someone shares an item, creates a workspace, changes a role, or removes a label. Those events flow into the Microsoft Purview audit log, the same one you already searched for SharePoint and exchange, so you don't need a new habit. For the basics, you open purview, pick the fabric activities, filter by a user or a date range, and read the results. If someone asks whether a person downloaded the quarterly numbers, that's where the answer sits. Keep one limit in mind though. Audit retention depends on your license. The default window may be shorter than the question you get asked. A request about something from fourteen months ago can arrive after the log has already let it go. Check your retention now before anyone needs it. The third place is the admin APIs. These are Rest calls that return the tenants inventory and activity as data. Which workspaces exist, who holds roles in them? Which items sit inside, and what happened over a given day. Many teams pull this into a lakehouse of their own, which is a fair use of the platform, and then build their own governance reports on top. This is where you get the view. The portal doesn't give you a list of every workspace with no owner, every workspace still sitting on a trial capacity. Every individual who holds admin without belonging to a group. Those aren't events. They're a snapshot of state. And the APIs are how you take one. Now, what can all this answer and what can't? It? Logs are good at who and when. Who exported the report, at what time, from which workspace. They're also good at counting how many exports last week, how many new workspaces, how many role changes they're weak on why a log shows that a person shared a lake house with an outside guest. It can't tell you whether the business had a reason, and they're weak on content. You'll see that a query ran. You won't always see which rows came back. For a few workloads, the detail is thin or arrives late, so treat a quiet log as a reason to check, not as proof that nothing happened. There's also a gap that catches people. A log only records what the platform sees. If someone copies data out through a connector running under a service account, the event shows the service account. The human behind it isn't there unless you tied them together earlier. So what do you do with all this? Build a habit that fits in an hour a week. Pick a small set of questions and ask them every time which workspaces appear this week and who owns each. Which role changes touched admin or member? What got exported or shared outside the tenant, and did any capacity cross into overage for questions. A short list beats a long dashboard because a short list gets read. Write down anything odd. Ask the owner and keep the notes. After two months, you'll see your own tenants normal and anything outside it will stand out fast. That's what the logs give you a record of what already happened, searched after the fact. What they can't give you is a statement of what should have happened. And that has to come from the model you put in place beforehand. Building a governance model that survives growth. Most governance documents die in a shared folder. They're long. They're careful, and they describe a tenant that no longer exists by the time the review meeting happens. The problem isn't effort, it's that the document tries to predict every case. And fabric produces new cases every week. So build the model around ownership instead. Three tiers. Each one answers a different question. Tenant admins own the rules that apply everywhere. The tenant settings, the purview labels, the audit retention. The list of who may certify this group is small. Its job is to set limits not to approve work capacity. Admins own the pool. They decide what runs on it, what utilization, and answer for the bill. Usually that's a platform lead or someone from the central data team, plus a named cost owner from the business workspace. Owners own the content. They decide who holds which role, what gets labeled, and when an item has outlived its use, their closest to the data. So they're the only ones who can tell if a thing is still needed. Three tiers notice what each tier doesn't do. Tenant admins don't review every workspace. Workspace owners don't touch tenant settings. That split is what keeps the model from collapsing under its own weight. Now give those tiers a lifecycle for steps. Request create review retire request means someone states what they need and why not a form with twenty fields, three answers who owns it, which domain it belongs in, and what kind of data it will hold. That last one decides everything that follows, including which label and which capacity. Create is where you remove the friction and this surprises people. Once the request is approved, the workspace should appear already configured, named by your pattern, assigned to the right capacity. Roles given to a security group, not to individuals. If creation is slow or manual, people skip the request and build in their personal space instead reviews the step. Almost nobody runs on a schedule. Every workspace owner confirms three things. The roles are still right. The labels are applied, the workspace is still in use. Quarterly is enough for most, and the admin APIs we covered can pull the list for you. So the review starts from data instead of memory. Retire is the other forgotten step. A workspace with no owner and no activity gets a notice, then a grace period. Then it's archived or deleted. Without that last step, every project you ever approved stays in the tenant forever, still holding roles and still costing something. Now who gets to create workspaces at all? You have a choice and it's a real trade. You can restrict creation to a named group, so every new workspace passes through an approval that gives you control and it makes you a bottleneck. Or you can leave creation open and rely on defaults and review to catch problems afterward. That's fast. And it's how sprawl starts. Most tenants land in the middle. A trained group of creators kept current with a short path to join it. Joining means finishing a half hour walk through on labels, roles and capacity. It costs the business a little time and it removes a lot of cleanup. Keep the documentation short enough to survive. One page for the rules, one page for the life cycle. A list of owners with names, not job titles that nobody updates. If it can't be read in five minutes, it won't be. That's the real shift here. You're not building gates that stop work. You're building guardrails that let work move quickly. Inside limits, gates ask for permission each time. Guardrails make the safe path the easy one. And once you have the model, the only thing left is the question of where to begin. Because a plan that waits for the perfect moment never starts.

01:15:39 Speaker: For the first thirty days. A practical admin plan. You don't need a perfect model by Friday. You need a first month with an order to it. Week one is inventory. Open the fabric admin portal and read every tenant setting top to bottom and write down which ones are still on their defaults. Then list the capacities and pay attention to the ones labeled trial. Each of those has an end date, so put the dates in a calendar. Then pull the workspace list through the admin APIs or the monitoring workspace. For each workspace, you want a name and owner, a capacity, and a last used date. You'll find some with no owner. That's normal and it's the point of the exercise. Nothing changes, yet you're only looking. Week two is where you start to tighten. Create security groups for fabric creators, for workspace admins, and for the people who may certify. Then scope the enabling of fabric. The trial setting and workspace creation to those groups. Next, go through the workspaces from week one and swap individual role assignments for group assignments. Start with the ones holding anything sensitive and leave the rest for the review cycle. Then turn off what nobody has asked for. Publish to web if it's on, is the usual first candidate. External sharing is the second. If someone needs either, they'll tell you and then you'll know who and why. Week three is about labels and logs. Confirm the tenant setting that lets fabric use sensitivity labels and check which groups can apply them. Set a default label in your label policy so new items start protected. Then confirm that fabric events are showing up in the purview audit log and check how long your license keeps them. That retention window is easy to miss, and it decides which questions you can answer later. Add one more thing to this week. Run the four weekly questions from the logging section. Once by hand, it'll feel slow. It's meant to. Week four is layout and money. Decide how many capacities you actually need using the design choices we covered, and move any workspace that sits on a trial onto a paid one. Name a cost owner for every capacity and set a pause schedule for anything that isn't production at the cost center tag. Then agree on who sits in each ownership tier with real names, because that list is what turns a plan into something people can act on. Now the handoffs. They matter as much as the settings to security. Hand the tenant settings. list, the label policy and the audit retention window. Ask them to own the review of admin role holders and guest access to finance. Hand the capacity list with owners. The pause schedule and the four cost rules. Ask them for the invoice breakdown each month so the two of you compare it against the metrics app to the data team. Hand the creator group the workspace request path and the naming rule. Tell them plainly what changed and why. They'll accept limits faster when the safe path is also the quick one. Three groups. Three short documents. None of them longer than a page. By day thirty, you won't have solved fabric governance. You'll have something better for a first month. A tenant where every capacity has an owner. Every setting has been read on purpose and nothing important runs on a date nobody wrote down, and even then the same mistakes will show up. They're predictable and they're worth naming before they find you. Common failure patterns for failures show up again and again. Different companies, same shape. The first one is the trial that became production. A team built something on a trial capacity to prove an idea. It works. Other people start relying on it, and a month later it feeds a dashboard that a director opens every morning. Nobody moved it because nobody remembered it was a trial. Then the trial ends, the grace period runs out and the dashboard goes dark on a Tuesday. The tool did what it was built to do. The failure was that a temporary thing was allowed to turn into a dependency without anyone signing for it. The second is everyone being a workspace admin, it starts as a shortcut. Someone needs access quickly and admin is the role that stops the questions. So the project lead gets it. Then the analyst, then the contractor, then the person who left in March. Months later, a dozen people can change roles, delete items, and share outside the tenant. Nobody chose that. It piled up one favor at a time, and no review ever took any of it back. The third is labels that exist but aren't applied. You built the taxonomy. You published the policy. The labels look great in the admin center, but the items in the workspaces carry nothing because applying a label was always somebody else's step, and nobody was told it was theirs. So the protections you designed sit there waiting for data that never arrives with a tag on it. And the fourth is dev and prod sharing one capacity. It's cheaper on paper. Then an engineer tests a heavy notebook on a Thursday afternoon, the pool runs hot, and the executive report that runs on the same capacity slows to a crawl, then starts failing. One bad query stalled. Both the people who got hurt weren't even in the same team. Now look at those four together. Not one of them is a bug. The platform behaved exactly as documented every time each one traces back to the model. We treated fabric like another workload, something a team turns on and runs. But it's a shared platform with one pool, one lake, and one set of people holding keys. When ownership is missing at the start, the platform fills the gap with defaults and defaults favor speed, which means the fix is never a setting. It's a name next to every capacity, every workspace, and every label decision. Auto. From workloads to platform. Here's the shape of it, plain and simple. The capacity is the pool. Everything draws from it, and when it runs dry, everyone feels it. One lake is the store, one lake with the walls knocked down. Workspaces are the boundaries, the only walls left. So they need owners. Tenant settings and identity are the controls where you decide who gets in and what they can do. Once inside, that's the shift you use to manage workloads one app at a time, each with its own edges. Fabric runs as one platform, and your tenant is the container for all of it. And here's the consequence that doesn't go away. Ignore fabric and you still own the bill. You still own the risk the invoice reaches your organization. Whether or not you ever opened the admin portal. The exposure sits in your tenant, under your identity, inside your compliance boundary. Ignoring it doesn't move it to someone else. It just means you find out later if this changed how you think about fabric, leave a review for the podcast. It helps more admins find this view of the platform, the one that starts from the tenant instead of the vendor demo. And follow me on LinkedIn. Tell me which topic you want next. Purview, copilot governance, whatever keeps you up at night. One last thing. This episode was supported by Stellar Migrator for exchange, a tool for mailbox migrations. It fits the theme we started with Where your data Lives shapes every decision that comes after it. Plan the move before you choose the platform. You didn't ask for a data platform, but fabric is already running in your tenant. The lake is already there.