Here’s a brutal truth: managing BI without ALM is like building a skyscraper with Jenga blocks. It all looks fine—until someone breathes on it. Here’s what this video will give you: first, how to treat Power BI models as code, second, how Git actually fits BI work, and third, how pipelines save you from late-night firefighting. Think of it as moving from duct tape fixes to a real system. We’re not here to act like lone heroes; we’re here to upgrade our team’s sanity. Want the one‑page starter checklist? Subscribe or grab the newsletter at m365 dot show. And before we talk about solutions, let’s face the core mess that got us here in the first place.Stop Emailing PBIX Files Like It’s 2015Stop emailing PBIX files around like it’s still 2015. Picture this: it’s Monday morning, you open your inbox, and three different PBIX files land—each one proudly labeled something like “Final_V2_UseThisOne.” No big deal, just grab the most recent timestamp, right? By lunchtime you’ve got five more versions, two of them shouting “THIS ONE” in all caps, and one tragic attempt called “Final_FINAL.” That’s not version control. That’s digital roulette. Meanwhile, you’re burning hours just figuring out which file is “real” while silently hoping nobody tweaked the wrong thing in the wrong copy. On paper, firing PBIX files around by email or Teams looks easy. One file, send it over, done. Except it never works that way. Somebody fixes a DAX measure, another person reworks a relationship, and a third adds their “quick tweak.” None of them know the others did it. Eventually all these edits crash together, and your so-called “production” report looks like Frankenstein—body parts stitched until nothing fits. And when things break, you’re left asking why half the visuals won’t even render anymore. The real danger isn’t just messy folders. It’s the fact you can lose days of work in one overwrite. That polished report you built last week? Gone—replaced by a late-night hotfix someone dropped into “Final.pbix.” Now you’re not analyzing, you’re redoing yesterday’s work while cursing into your coffee. It feels like two people trying to edit the same Word doc offline, hand-merging every edit, then forgetting who changed what. And suddenly you’re back in that Bermuda Triangle of PBIX versions with no exit ramp. Here’s a better picture: imagine ten people trying to co-author a PowerPoint deck—but not in OneDrive. Everyone has their own laptop copy, they all email slides around, and pray the gods of Outlook somehow keep it consistent. Kim’s pie chart is slotting into slide 8 on her version but slide 12 in Joe’s. Someone else pastes “final numbers” into totals that already changed twice. Everyone pretends it’ll come together in the end, but you know it’s cursed. Power BI isn’t any different—PBIX files don’t magically merge, they fracture. And yes, the cost is real. Teams I’ve worked with flat out admit they waste hours untangling this. Not because BI is impossible, but because someone worked off a stale file and buried the “real one” in their desktop folder. Instead of delivering insights, these teams run detective shifts—who changed which table, who overwrote which visual, and why the version sent Friday doesn’t match the one uploaded Monday. Business intelligence becomes business archaeology. Of course, some teams argue it’s fine: “We’re small, email works. Only two or three of us.” Okay, but reality check—at two people it might limp along for a while. Do a quick test: both of you edit the same PBIX in parallel for a single sprint. Count how many hours get wasted reconciling or fixing conflicts. My bet? Enough that you’ll never say “email works” again. And the second your team grows, someone takes PTO, or worse—someone experiments directly in production because deadlines—everything falls apart. Look, software dev solved this problem ages ago. Treat your assets like code. Put them somewhere structured. Track every single change. Why are BI teams still passing PBIX files back and forth like chain emails your grandma forwards? The file-passing era isn’t collaboration, it’s regression. So let’s call it what it is: emailing PBIX files isn’t teamwork, it’s sabotage with a subject line. The only way out is to stop treating PBIX as a sacred artifact and start thinking of your model as code. That mental shift means better history, cleaner teamwork, and fewer nights spent piecing together ten mismatched “Final” files. So: stop passing PBIX. Next: how to treat the model like code so Git can actually help.Treating Power BI Models Like Real CodeNow let’s talk about the shift that actually changes everything: treating Power BI models like real code. Think about it. That PBIX file you’ve been guarding like it’s the last donut in the office fridge? It’s one giant sealed box. You know it changed, but you have zero visibility into *what* changed, *when*, or *who touched it*. That’s because PBIX is stored in a single file format that Git treats like a blob—so out of the box, you don’t get meaningful diffs, just “yep, the file is different.” That’s as helpful as someone telling you your car “looks louder than yesterday.” This is why so many teams shove a PBIX into Git, stare at the repo, and wonder why nothing useful shows up. Git’s not broken, it’s blind. It can’t peek inside that binary-like package to tell you a DAX measure was renamed or a relationship got nuked. To Git, every version looks like the same sealed jar. So what’s the workaround? You split the jar open. Instead of leaving the entire model locked in that one file, you pull out the stuff that matters—tables, measures, roles, relationships—and represent them as plain text. There are tools that can extract model definitions into text-based artifacts. Once you’ve done that, Git suddenly understands. Now a commit doesn’t just say “the PBIX moved.” It reads like: “Measure SalesTotal changed from SUM to AVERAGE,” or “Added relationship between Orders and Products.” That difference—opaque blob versus readable text—is the foundation for real collaboration. If you want a quick win that proves the point: in the next 20 minutes, take one dataset, export just a piece of its model into a text format, and drop it into a trial Git repo. Make one tiny edit—change a DAX expression or add a column—and check what Git shows in the diff. Boom. You’ll see the exact change, no detective work, no guessing game. That little test shows the value before you roll this out across an entire team. Once your model looks like code, the playbook opens up. Dev teams live by ideas like branching and merging, and BI teams can borrow that without selling their souls to Visual Studio. Think of a branch as your own test kitchen—you get your space, your ingredients, and you can experiment without burning the restaurant menu. When you’re ready, merge brings the good dishes back into the main menu, ideally after someone else tastes it and says, “yeah, that actually works.” The explicit takeaway: branch for safety, merge after review. It’s not a nerd ceremony; it’s just insurance against wrecking the main file. The usual pushback is, “But my BI folks don’t code. We don’t want to live in a terminal.” Totally fair. And the good news is—you don’t have to. Treating models like code doesn’t mean learning C# at midnight. It just means the things you’re already doing—editing DAX, adding relationships, adjusting tables—get logged in a structured format. You still open Power BI Desktop. You still click buttons. The difference is your changes don’t vanish into a mystery file—they get tracked like real work with proper accountability. And when that happens, the daily pain points start to disappear. Somebody breaks a measure? Roll it back without rolling back the whole PBIX. Need to know who moved your date hierarchy? The log tells you—no Teams witch hunt required. Two people building features at the same time? Possible, because you’re not stomping on the same single file anymore. The entire BI cycle goes from “fragile file juggling” to “auditable, reversible, explainable changes.” Bottom line: treating models as code isn’t about making BI folks pretend to be software engineers. It’s about giving teams a structure where collaboration is safe, progress is reversible, and chaos isn’t the default state of work. That’s the foundation you need before layering on heavier tools. And since we’re talking about structure, there’s one system that’s been giving developers this kind of safety for years but makes BI folks nervous just saying the name. It’s not glamorous, and most avoid it like they avoid filing taxes. But it’s exactly the missing piece once your models are text-based.Git: The Secret Weapon for BI TeamsGit: the so‑called scary tool that everyone thinks belongs to hoodie‑wearing coders in dark basements. Here’s the reality—it’s not mystical, it’s not glamorous, and it’s exactly the kind of history book BI teams have been missing. If you’ve ever wanted a clean log that tells you who changed what, when it happened, and why—it was built for that. The only reason it ever felt “not for BI” is because we’ve been trapped in PBIX land. Once your model is extracted into text, Git isn’t some alien system anymore. It’s just the ledger we wish we had back when “Final_v9.pbix” came crashing through our inbox. The common pushback goes something like this: “PBIX files aren’t code, so why bother with Git?” That’s developer tunnel vision talking. Git doesn’t care whether you’re storing C#, JSON, or grocery lists—it just tracks change. If you’ve extracted your BI model into text artifacts, Git can store every line, log every tweak, and show you exactly what changed. Stop treating Git like a club you need a comp‑sci membership to join. It’s more like insurance: cheap, reliable, and a lifesaver when someone nukes the wrong measure on a Friday afternoon. Think of Git as turning on track changes in a Word doc—except instead of one poor soul doing all the e
Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.
If this clashes with how you’ve seen it play out, I’m always curious. I use LinkedIn for the back-and-forth.
