Episode Details

Admins, remember when Power BI Premium felt like your biggest headache? Overnight, you’re suddenly a Fabric Administrator, staring at domains, capacities, and tenant configs like a set of IKEA instructions written in Klingon. Microsoft says this makes things “simpler.” Our experience shows it just means fifty new moving parts you didn’t ask for. By the end, you’ll know what to lock down first, how to design workspaces that actually scale, and how to avoid surprise bills when capacity goes sideways. Subscribe to the M365.Show newsletter so you get our Fabric survival checklist before chaos hits. Let’s start with domains. Microsoft says they “simplify organization.” Reality: prepare for sprawl with fancier nametags.Domains Aren’t Just New LabelsDomains aren’t just another batch of Microsoft labels to memorize. They change how data, people, and governance collide in your tenant—and if you treat them like renamed workspaces, you’ll spend more time firefighting than managing. On the surface, a domain looks tidy. It’s marketed as a logical container: HR gets one, Finance gets one, Marketing gets one. Sounds neat until you realize each domain doesn’t just sit there quietly—it comes with its own ownership, policies, and permission quirks. One team sees it as their sandbox, another sees it as their data vault, and suddenly you’re refereeing a brawl between groups who have never once agreed on governance rules. The scope is bigger too. Workspaces used to be about reports and maybe a dataset or two. Now your Marketing domain doesn’t just hold dashboards—it’s sucking in staging pipelines, raw data ingests, models, and random file dumps. That means your business analyst who just wanted to publish a campaign dashboard ends up sharing space with a data engineer pushing terabytes of logs. Guess who dominates that territory? Not the analyst. Then comes the permission puzzle. You’re not just picking Viewer, Contributor, or Admin anymore. Domains bring another layer: domain-level roles and domain-level policies that can override workspace rules. That’s when you start hearing from users: “Why can’t I publish in my own workspace?” The answer is buried in domain settings you probably didn’t know existed when you set it up. And every one of those support pings ends up at your desk. Here’s the metaphor that sticks: setting up domains without governance is like trying to organize your garage into “zones.” You put tools on one wall, bikes in another corner, boxes on shelves. Feels under control—until the neighbors dump their junk in there too. Now you’re tripping over someone else’s lawnmower trying to find your screwdriver. That’s domains: the illusion of neat order without actual rules. The punchline? Domains are an opportunity for chaos or control—and the only way you get control is by locking a few things in early. So what do you lock? First 30 days: define your domain taxonomy. Decide whether domains represent departments, projects, or purposes. Don’t let people invent that on the fly. First 60 days: assign single ownership with a clear escalation path. One team owns structure, another enforces usage, and everybody else knows where to escalate. First 90 days: enforce naming rules, then pilot policies with one team before rolling them out everywhere. That gives you a safe zone to see how conflicts actually surface before they become tenant-wide tickets. And what do you watch for along the way? Easy tells that a domain is already misconfigured: multiple near-identical domains like “Sales,” “Sales Reporting,” and “Sales 2025.” Owners you’ve never heard of suddenly holding keys to sensitive data. Users reporting mysterious “can’t publish” errors that resolve only when you dig into domain policies. Each of these is a canary in the coal mine—and if you ignore them, the sprawl hardens fast. We’ve seen domain sprawl happen quickly when teams can create domains freely. It’s not hypot