M365.FM - Modern work, security, and productivity with Microsoft 365 – Details, episodes & analysis

Dataverse licensing Power Apps: this episode of M365.fm breaks down why your Dataverse‑backed Power Apps project suddenly feels “too expensive” and how to design licensing, capacity, and environments so costs stay predictable instead of exploding right before go‑live. Mirko Peters starts with the Dataverse cost illusion: everyone assumes it “comes with” Microsoft 365, until premium connectors, per‑app vs. per‑user licenses, and separate storage tiers quietly stack up into a bill that shocks both project owners and finance.

Mirko dissects the invisible premium inside Dataverse: licensing models that multiply with every additional app, environment, and user; capacity packs for database, file, and log storage; and API limits that push you toward higher‑tier licenses when automation gets serious. He explains why Dataverse is not “just a database” but a full data platform with enterprise compliance, security, and transactional guarantees—and why that power is overkill and overpriced for some scenarios, but absolutely justified for others. You’ll learn how premature Dataverse adoption can double or triple your costs when a simpler setup would have been enough.

The episode then walks through the main licensing landmines. Mirko explains the difference between M365‑included Power Apps versus premium Dataverse usage, why “everyone is already licensed” is a myth, and how per‑app vs. per‑user choices change your cost curve as soon as a second app or environment is added. He also covers external users and portals, clarifying why guest access in Azure AD is not the same as free Dataverse usage, and how capacity consumption for external scenarios can surprise even experienced architects if it isn’t modeled upfront.

You also get a practical playbook for designing Dataverse architectures that your budget can live with. Mirko outlines how to forecast capacity using environments × apps × users × data growth, when to stick with SharePoint or SQL and when Dataverse is truly worth the premium, and how to use sandboxes, shared environments, and careful connector choices to avoid unnecessary license escalation. By the end, you’ll have a clear view of when Dataverse is the right engine, when it’s an expensive luxury, and how to keep your next Power Apps project from becoming a licensing horror story.

WHAT YOU WILL LEARN

• Why Dataverse introduces an “invisible premium” on top of Microsoft 365 and standard Power Apps.
• How per‑app vs. per‑user licensing, environments, and external users multiply your total cost.
• How Dataverse storage (database, file, log) and API limits impact both architecture and budget.
• When Dataverse is overkill and when its security, compliance, and transaction features are worth the price.
• How to forecast capacity and design an environment strategy that avoids last‑minute licensing shocks.

THE CORE INSIGHT

Dataverse is not too expensive—using it blindly is. Once you understand how licensing, capacity, and environments really work, you can reserve Dataverse for the apps that truly need its enterprise guarantees and keep everything else on cheaper foundations, turning “licensing surprise” into deliberate, transparent design.

WHO THIS EPISODE IS FOR

This episode is ideal for Power Apps makers, solution architects, IT leaders, and finance partners who are planning Dataverse‑backed apps or discovering premium requirements late in the project. It is especially valuable if you need to justify Dataverse to budget owners, avoid hidden licensing traps, and build a repeatable cost model for your Power Platform portfolio.

ABOUT THE HOST

Mirko Peters is a Microsoft 365 and Power Platform consultant focused on building governed, scalable low‑code platforms with Dataverse, Power Apps, Power Automate, and Microsoft 365. Through M365.fm, he shares practical cost‑control patterns, licensing playbooks, and real‑world migration stories that help organizations ship serious apps without losing control of their Power Platform spend.

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

Copilot Notebooks governance risk: this episode of M365.fm reveals why Copilot Notebooks look like a productivity upgrade but quietly create a compliance and data‑lineage nightmare inside Microsoft 365. Mirko Peters shows how every “innocent” AI summary becomes a new, unlabeled data artifact that inherits no sensitivity labels, retention policies, or Purview visibility—turning powerful contextual answers into governance blind spots.

Mirko starts by explaining what Copilot Notebooks really are: not tidy documents, but dynamic aggregation layers that pull context from SharePoint, OneDrive, Teams, email, and more into a temporary AI workspace. Each prompt fuses multiple sources into new text that lives in the cracks between systems—no clear owner, no clear location, and no automatic policy inheritance. You’ll learn why this “composite content” behaves like a scratch pad in the UI, but behaves like a Shadow Data Lake from a compliance perspective.

He then unpacks the moment governance breaks. When Copilot blends HR, finance, and operations data into a single paragraph, the original labels and retention rules effectively fall off. The AI‑generated summary looks harmless (“engagement trends improved last quarter”), yet encodes insights from regulated sources that are no longer traceable to their origin. Mirko explains how Purview and DLP are built to see files and objects, not ephemeral AI context, and why that gap means Notebook outputs can be copied into emails, documents, and decks without any of the original controls following them.

The episode goes deep on data lineage and regulatory impact. Mirko shows how Notebooks sever the “family tree” of information: Copilot does not embed source citations or structured provenance, so auditors cannot see which HR record, finance sheet, or legal memo fed a specific sentence. He walks through concrete scenarios where GDPR “right to be forgotten,” PCI, or internal retention rules become impossible to prove, because derivative Notebook content has been pasted into downstream assets that no catalog or sensitivity label can reliably discover.

Finally, you get a pragmatic governance response plan. Mirko outlines how to frame Copilot Notebooks as high‑risk workspaces, when and where to allow them, and which guardrails to apply: user education, restricted use cases, export policies, and stronger Purview monitoring around AI‑generated content. He shares language you can use with security, legal, and business leaders to shift the question from “Is Copilot safe?” to “How do we keep derivative AI content inside our existing governance model instead of creating a hidden parallel system?”.

WHAT YOU WILL LEARN

• Why Copilot Notebooks create unlabeled, policy‑free derivative content that traditional governance cannot see.
• How aggregation across SharePoint, OneDrive, Teams, and email turns AI summaries into a Shadow Data Lake.
• How data lineage, auditability, and “right to be forgotten” break when AI outputs have no embedded provenance.
• Which Purview and DLP assumptions fail in Notebook scenarios—and where the real regulatory exposure sits.
• How to design practical guardrails, usage patterns, and communication so Notebooks stay inside governance boundaries.

THE CORE INSIGHT

Copilot Notebooks don’t just summarize your data—they quietly dissolve your governance model. Unless you treat Notebook outputs as first‑class regulated content with owners, policies, and lineage, every productive AI session becomes a small compliance centrifuge, spinning sensitive inputs into untracked, unlabelled text.

WHO THIS EPISODE IS FOR

This episode is ideal for security and compliance teams, Microsoft 365 and Purview administrators, data protection officers, and digital workplace leaders evaluating Copilot Notebooks. It is especially valuable if you are under regulatory pressure and need to understand how AI‑generated summaries fit (or fail to fit) into your existing classification, retention, and audit frameworks.

ABOUT THE HOST

Mirko Peters is a Microsoft 365 consultant and digital workplace architect focused on building governed, scalable platforms with Microsoft 365, Purview, Copilot, and the Power Platform. Through M365.fm, he shares practical governance patterns, AI risk stories, and implementation playbooks that help organizations adopt Copilot capabilities without losing control of compliance and data protection.


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

Power Apps Generative Pages licensing: in this episode of M365.fm, Mirko Peters breaks down the “free lunch” illusion behind Generative Pages in Power Apps and explains how a single click on “Describe your page” can silently upgrade you into Dataverse‑backed, premium‑licensed territory. He shows how AI‑generated pages look like harmless prototypes—pretty calendars, dashboards, and forms built from a sentence—while under the hood they deploy Dataverse schema, model‑driven plumbing, and premium capabilities that finance will absolutely notice later.

Mirko starts with what Generative Pages actually do. Copilot takes your natural‑language prompt, uses existing Dataverse tables or creates new ones, and scaffolds a React‑based page inside a model‑driven app—complete with relationships, security, and automation hooks. It feels like no‑code magic, but the reality is scaffolding, not sorcery: the AI wires you into Dataverse’s full enterprise stack, with all the compliance and licensing implications that come with it. What looks like a quick experiment is, from the platform’s perspective, a premium app.

He then exposes the Dataverse “silent upgrade” most makers never see. As soon as a Generative Page binds to Dataverse, your app crosses from standard connectors (SharePoint, Excel) into premium land, where every active user now requires a Power Apps Premium license and your environment consumes Dataverse capacity for database, file, and log storage. Mirko explains why this is by design: Dataverse brings relational integrity, audit trails, and enterprise security—but that power is priced accordingly, and Generative Pages are built on the assumption you’re ready to pay for it.

The episode also dismantles the SharePoint virtual table mirage. Many teams believe they can dodge Dataverse licensing by exposing SharePoint lists as virtual tables and letting Generative Pages sit on top “for free.” Mirko explains why this still relies on Dataverse as the metadata and security engine: virtual tables are Dataverse assets, not shortcuts around it. The platform still counts premium usage, and you end up with Dataverse complexity plus SharePoint limitations, instead of a genuinely cheaper architecture.

Throughout the conversation, Mirko gives you a practical decision framework. You’ll learn when Generative Pages plus Dataverse are absolutely worth it—regulated workloads, complex relational models, long‑lived apps—and when you should stick to Canvas Apps on standard connectors or other patterns to avoid surprise licensing explosions. He closes with concrete steps for platform owners: documenting premium patterns, setting environment guardrails, educating makers about the “generate = premium” rule, and budgeting Generative Pages as enterprise assets instead of free experiments.

WHAT YOU WILL LEARN

• What Generative Pages really do under the hood—Dataverse schema, model‑driven plumbing, and React‑based UI.
• How a single AI‑generated page flips your app from standard to premium licensing and Dataverse capacity.
• Why SharePoint virtual tables do not avoid Dataverse costs and often create a fragile hybrid architecture.
• When Generative Pages plus Dataverse are the right choice, and when cheaper Canvas/standard patterns are better.
• How to educate makers and design environment guardrails so “AI magic” doesn’t blow up your licensing budget.

THE CORE INSIGHT

Generative Pages are not free UI toys—they are Dataverse deployment buttons with good marketing. Once you see that “Describe your page” really means “Stand up a premium, governed Dataverse app,” you can stop sleepwalking into licensing traps and start treating these pages like the enterprise assets they actually are.

WHO THIS EPISODE IS FOR

This episode is ideal for Power Apps makers, solution architects, Power Platform admins, and IT or finance leaders who are piloting Generative Pages or seeing unexpected premium usage in their tenant. It is especially valuable if you need clear language and a concrete framework to explain to stakeholders when Generative Pages are worth the Dataverse investment—and when they are an expensive way to solve a simple problem.

ABOUT THE HOST

Mirko Peters is a Microsoft 365 and Power Platform consultant focused on building governed, scalable low‑code platforms with Power Apps, Dataverse, Power Automate, and Microsoft Copilot. Through M365.fm, he shares practical licensing playbooks, architecture patterns, and real‑world migration stories that help organizations get the benefits of AI‑assisted app building without losing control of costs and governance.



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

Look, we all joke about Microsoft licensing being a Rubik’s cube with missing stickers—but Dataverse isn’t just that headache, it’s the moment you admit your SharePoint lists and SQL leftovers can’t carry “version 3.0” of your app anymore. In this episode, we start from exactly where most teams are stuck: business‑critical processes living in oversized SharePoint lists, half‑documented SQL databases, and Power Apps that bend under the weight of added columns, lookups, and flows. You’ll hear why Dataverse is more than “a nicer list”—proper relationships, row‑ and field‑level security, auditing, APIs—and how migration pain is usually the bill for years of duct‑tape design rather than some cruel Microsoft upsell. We walk through the real trade‑offs between Lists, Dataverse, and SQL Server so you know when to stay, when to move, and how to avoid the classic trap of discovering premium licensing only after you’ve gone all‑in.

WHAT EVEN IS DATAVERSE, AND WHY ISN’T IT JUST ANOTHER LIST?

https://www.spreaker.com/cms/episodes/67867890/edit/info?filter=NETWORK&network=18613266We start by killing the “Dataverse = fancy list” myth. Dataverse is built as the data backbone for the Power Platform—tables, relationships, role‑based security, auditing, and API endpoints you can depend on—while SharePoint lists are brilliant for quick capture and lightweight apps but buckle once you stack relationships, lookups, and scale. You’ll hear real scenarios where a simple tracker list quietly grew into a mission‑critical app: flows started failing, view thresholds hit, permissions became unmanageable, and suddenly Dataverse didn’t look like overkill anymore, it looked like the life raft. We give you a three‑question gut‑check you can run on any workload (relationships, security, long‑term criticality) to decide if staying on Lists is realistic or if you’re already betting your business on something that was never meant to scale.

THE GOOD, THE BAD AND THE UGLY: LISTS VS DATAVERSE VS SQL

https://www.spreaker.com/cms/episodes/67867890/edit/info?filter=NETWORK&network=18613266Next, we stop pretending any of these tools are perfect. Lists win on speed and zero extra license friction; they’re fantastic for prototypes, trackers, and genuinely small processes—but overload them and you’re fighting view limits, broken lookups, and flows that stall at the worst possible moment. Dataverse gives you structural integrity—normalized tables, relationships, security, auditing, and automation—but it brings real costs in storage, premium licensing, and skill requirements that you must plan for early instead of discovering during rollout. SQL Server still has the deepest power and history, but for most maker‑led Power Platform scenarios it’s effectively locked behind DBA skills, permission complexity, and governance overhead that leaves citizen developers frozen. We break down where each fails, when each shines, and how to avoid choosing a tool on day one that guarantees emergency tickets six months later.https://www.spreaker.com/cms/episodes/67867890/edit/info?filter=NETWORK&network=18613266

THE COST NOBODY PUTS IN THE DEMO SLIDE

https://www.spreaker.com/cms/episodes/67867890/edit/info?filter=NETWORK&network=18613266Then we talk about money and time—the part that never appears in the marketing deck. Dataverse’s real cost doesn’t stop when the app loads; storage, premium capacity, and capability‑based licensing all stack up over time. We walk through a budgeting checklist you can actually use: estimate data growth, identify premium connectors and features, check which licenses your users really have, and factor in the skills ramp you’ll need so Dataverse isn’t just “that thing only one person understands.” You’ll learn why relying on trials and assumptions is the fastest way to get burned, how to bring procurement into the conversation before migration, and how to frame Dataverse cost against the hours you currently burn patching broken lists, flows, and shadow SQL instances.

WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67867890/edit/info?filter=NETWORK&network=18613266

• The real differences between SharePoint lists, Dataverse, and SQL Server—beyond the marketing slides.
• A practical gut‑check to decide when a list has outgrown itself and needs Dataverse.
• The structural benefits Dataverse brings: relationships, security, auditing, and APIs for serious Power Platform apps.
• The hidden costs of Dataverse (storage, premium features, skills) and how to budget for them up front.
• Why SQL still matters, but often isn’t the right foundation for low‑code makers without DBA support.

THE CORE INSIGHT

https://www.spreaker.com/cms/episodes/67867890/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that Dataverse isn’t “the expensive option,” it’s the platform you reach for when you stop pretending a glorified list or legacy SQL box can safely run a business‑critical app. Migration pain is real—but it’s also the price of finally getting proper relationships, security, and governance instead of living in a swamp of brittle lists and half‑managed databases. Once you choose the right data platform for the right job—and budget honestly for Dataverse where it fits—you trade surprise outages and hidden risk for something boring, predictable, and scalable.

https://www.spreaker.com/cms/episodes/67867890/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67867890/edit/info?filter=NETWORK&network=18613266

• Power Platform makers stuck between “just use a list” and “we really should move to Dataverse.”
• Solution architects deciding when to standardize on Dataverse vs SQL Server for new apps.
• Microsoft 365 admins and governance teams dealing with oversized lists and shadow apps.
• Leaders who need to understand Dataverse licensing, cost, and migration impact before signing off.

ABOUT THE AUTHOR / HOST

https://www.spreaker.com/cms/episodes/67867890/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365 and Power Platform consultant and host of the M365.FM podcast, helping organizations treat Microsoft 365, Dataverse, SQL, and Power Apps as one integrated operating system instead of a patchwork of lists, legacy databases, and one‑off apps. He works with teams running on Microsoft 365 and Azure to design architectures, migration paths, and governance so that Dataverse, SharePoint, and SQL each do the job they’re best at—without surprise costs or weekend‑killing outages.

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

Picture your data as a swarm of goblins: messy, multiplying in the dark, and definitely not helping you win over users. Drop Copilot into that chaos and you don’t get magic productivity—you get polished wrong answers: outdated contract summaries, conflicting numbers, and “confident” nonsense that looks like it came from 2017. The fix isn’t another slide deck, it’s hunting those goblins before rollout: cleaning a small, high‑value slice of content, tightening metadata and governance, and proving Copilot works there first. In this episode, I walk through the Top 10 actions that make Copilot genuinely useful—concrete steps you can run this week—not theory, plus a free checklist at m365.show so your rollout doesn’t fail before anyone even touches it.

WHY DEPLOYMENTS FAIL BEFORE DAY ONE

https://www.spreaker.com/cms/episodes/67860348/edit/info?filter=NETWORK&network=18613266Too many Copilot deployments fail before users ever give it a fair shot—not because of a bad Microsoft update, but because we flip the switch on top of a dumpster‑fire data estate. When your tenant is full of untagged files, duplicate spreadsheets, “Final\_v7\_REALLY.xlsx” versions, and contract libraries where expired drafts still pretend to be current, Copilot just turns that garbage into fluent garbage. Users ask simple questions like “show me open contracts with supplier X,” get answers mixed with outdated or wrong documents, and immediately label the tool “unreliable.” Trust dies on the first bad answer, not the tenth—and once hallway chat brands Copilot as “just another gimmick,” adoption flatlines no matter how much you spent on licenses or comms. The only way out is to start small and surgical: clean one critical content area, enforce structure and metadata, connect Copilot to that slice, and use the before/after difference as your internal case study for everything else.

HOW ORGANIZATIONS GOT PEOPLE TO WANT COPILOT

https://www.spreaker.com/cms/episodes/67860348/edit/info?filter=NETWORK&network=18613266The teams that made Copilot stick didn’t win with strategy decks, they won with visible, local wins that made people ask, “Why don’t we have this?” Instead of a big‑bang rollout to everyone, they ran tight pilots: small groups in finance, sales, or operations where real work—report prep, status summaries, email drafts—was measured before and after Copilot. When analysts suddenly saved hours on monthly reporting or backlogs shrank because updates wrote themselves, the story spread through Teams chats and hallway conversations, not just corporate comms. That “taco bar effect”—seeing another team get something clearly better—turned Copilot from a tolerated tool into something people queued up for, flipping the usual pattern where IT pushes adoption into one where demand comes from the business.

FRAMEWORKS THAT DON’T FEEL LIKE SALES PITCHES

https://www.spreaker.com/cms/episodes/67860348/edit/info?filter=NETWORK&network=18613266Classic change‑management frameworks can feel like MBA theater, but stripped down, something like ADKAR actually works for Copilot when you translate it into user language. Awareness becomes short, role‑specific demos; Desire is powered by one or two concrete tasks where Copilot clearly saves time or improves quality; Knowledge comes from micro‑learning and checklists, not 40‑slide decks. Ability shows up as safe sandboxes and non‑critical use cases where people can practice without fear, and Reinforcement means managers recognizing real wins and embedding Copilot into templates and daily routines. When you design rollout this way—small wins, real stories, and simple guardrails—you stop “selling AI” and start making it the obvious choice for the kind of work people already hate doing.

WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67860348/edit/info?filter=NETWORK&network=18613266

• Why messy, duplicate, and outdated content (“data goblins”) quietly destroy Copilot trust.
• How poor data governance kills AI projects before rollout, no matter how good the model is.
• How to run small, high‑impact pilots that create genuine demand instead of forced adoption.
• How to use a stripped‑down ADKAR approach (Awareness, Desire, Knowledge, Ability, Reinforcement) without turning it into an MBA exercise.
• The Top 10 practical actions—from cleaning one content set to micro‑learning and champions—that make Copilot actually useful this month, not “someday.”

THE CORE INSIGHT

https://www.spreaker.com/cms/episodes/67860348/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that Copilot doesn’t invent knowledge or fix chaos— it amplifies whatever you give it. If your tenant is full of shadow content and bad metadata, Copilot turns that into confident, wrong answers that kill trust on day one; if you first tame a focused slice of content, prove real time savings, and use simple frameworks to support users, Copilot turns into the assistant people actually ask for instead of another icon they ignore.

https://www.spreaker.com/cms/episodes/67860348/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67860348/edit/info?filter=NETWORK&network=18613266

• Microsoft 365 admins and architects planning Copilot rollouts in messy real‑world tenants.
• Business and IT leaders who need adoption based on real value, not just licenses assigned.
• Change and enablement teams looking for a Copilot playbook that doesn’t sound like a sales pitch.
• Power users and champions who want concrete steps to make Copilot accurate, trusted, and worth talking about.

ABOUT THE AUTHOR / HOST

https://www.spreaker.com/cms/episodes/67860348/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365 and AI governance consultant and host of the M365.FM podcast, helping organizations treat Microsoft 365, Copilot, and their content estate as one integrated operating system instead of a pile of shadow files and forgotten pilots. He works with teams running on Microsoft 365 and Azure to design data readiness, rollout, and enablement strategies so Copilot delivers accurate, grounded answers users trust—instead of becoming yet another tool they abandon after the first bad result.

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

Here’s the uncomfortable truth: without CI/CD, your beautiful Medallion Architecture is just a very expensive CSV swamp wearing a Gold badge. In this episode, we start right where most Fabric teams are stuck—Bronze ingestion scripts living in notebooks, Silver transformations hacked in prod, and Gold dashboards patched at 3 a.m.—and show how GitHub or Azure DevOps becomes the actual control plane. You’ll see how treating notebooks, SQL scripts, and pipeline configs as code (versioned, reviewed, and promoted) turns Fabric Warehouse from “please don’t break” into something you can roll back, test, and move between dev, test, and prod without midnight firefights.

BRONZE WITHOUT ROLLBACK – YOUR CSV GRAVEYARD

https://www.spreaker.com/cms/episodes/67853161/edit/info?filter=NETWORK&network=18613266Bronze is where the first goblins spawn: corrupted feeds, schema drift, duplicate loads—quietly poisoning everything upstream while pipelines still show a comforting green checkmark. We walk through how bad timestamps, header changes, and extra columns in “raw” zones become permanent damage when ingestion logic isn’t in Git and deployments go straight to production. You’ll learn three non‑negotiables for Bronze: keep every ingestion notebook/script in source control, parameterize connections and schemas instead of hard‑coding prod, and run pre‑deploy schema/dry‑run checks in CI so bad changes never hit your landing zone. With those guardrails, an ingestion failure becomes a quick rollback and redeploy—not a weeks‑long data‑rebuild panic.

SILVER: WHERE GOVERNANCE DIES QUIETLY

https://www.spreaker.com/cms/episodes/67853161/edit/info?filter=NETWORK&network=18613266Silver looks clean on the surface—standardized types, deduped rows, pretty column names—but this is where governance often dies in silence. When fixes live in ad‑hoc notebooks and “just this once” patches against production, dev, test, and prod stop matching, and you only notice when numbers don’t reconcile in front of leadership. We show how to force discipline into Silver: every transformation change goes through a pull request, automated data‑quality checks (nulls, uniqueness, schema compatibility) run in CI, and promotions happen only via pipelines—not manual edits. That way, Silver becomes the first layer where “what happens in dev is exactly what happens in prod,” instead of three different realities with the same table names.

GOLD AT 3 A.M. – ANALYTICS UNDER PRESSURE

https://www.spreaker.com/cms/episodes/67853161/edit/info?filter=NETWORK&network=18613266Gold is the only layer executives actually see—dashboards, KPIs, quarter‑end numbers—and it’s where shortcuts cost the most. One untested schema tweak in Silver or a hotfix in Gold can break trust instantly when financials or key metrics suddenly don’t match past reports. We talk about building mirrored environments (dev/test/prod) for Gold models and reports, wiring deployment pipelines from Git so only tested changes ship, and banning “panic SQL” edits in production warehouses. When GitHub or Azure DevOps becomes the single source of truth for Gold, 3 a.m. calls turn from “what changed?” into “which commit broke this?”—and that’s a problem you can actually solve.

WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67853161/edit/info?filter=NETWORK&network=18613266

• Why a Medallion Architecture without CI/CD is just structured chaos in Fabric Warehouse.
• How Bronze ingestion turns into a CSV graveyard without Git, schema checks, and rollback paths.
• How Silver quietly destroys governance when fixes live in ad‑hoc notebooks and prod‑only tweaks.
• How to make Gold analytics reliable under pressure with mirrored environments and pipeline‑driven deploys.
• How GitHub, Azure DevOps, and Fabric deployment pipelines together form a real GitOps model for your warehouse.

THE CORE INSIGHT

https://www.spreaker.com/cms/episodes/67853161/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that GitHub or Azure DevOps—not Fabric itself—decides whether your warehouse is safe. When every ingestion script, transformation, and Gold model lives in source control, moves through CI/CD checks, and promotes via pipelines, you stop betting your Medallion Architecture on luck and start treating it like real product code—with versions, tests, and rollbacks you can trust.
https://www.spreaker.com/cms/episodes/67853161/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67853161/edit/info?filter=NETWORK&network=18613266

• Fabric and data engineers tired of babysitting fragile Bronze, Silver, and Gold layers.
• BI and analytics leads who want real dev/test/prod discipline in Fabric Warehouse.
• Platform and DevOps teams integrating GitHub or Azure DevOps with Fabric for GitOps‑style workflows.
• Architects and consultants designing Medallion Architectures that actually survive schema drift and production pressure.

ABOUT THE AUTHOR / HOST

https://www.spreaker.com/cms/episodes/67853161/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365 and data platform consultant and host of the M365.FM podcast, helping organizations treat Microsoft 365, Fabric, and their warehouses as one integrated operating system instead of a pile of one‑off scripts and dashboards. He works with teams running on Microsoft 365, Azure, and Fabric to design Medallion Architectures, GitOps workflows, and CI/CD guardrails so that Bronze, Silver, and Gold layers stay versioned, testable, and recoverable—even when things go wrong at 3 a.m.



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

Here’s the catch Microsoft doesn’t highlight: Power Automate’s run history is time‑limited by default, tied to your plan and license—and once that retention window passes, your approval trail is gone as if it never existed. That’s fine for Microsoft’s storage bill, but terrible for audits, investigations, or basic accountability; designing without permanent logging is like deleting your CCTV before anyone checks the footage. In this episode, we break down why run history is only a temporary debugging aid, how to build durable approval logs outside that buffer, and how to redesign flows so you can restart from a specific stage, use dynamic approvers, and keep escalations and reminders under control instead of flooding inboxes.https://www.spreaker.com/cms/episodes/67846983/edit/info?filter=NETWORK&network=18613266

WHY YOUR FLOW HISTORY VANISHES (AND WHY IT MATTERS)

https://www.spreaker.com/cms/episodes/67846983/edit/info?filter=NETWORK&network=18613266Power Automate’s run history looks comforting—until you realise it’s a rolling window, not a permanent archive. Retention is defined by your tenant configuration and licensing, so older approvals simply age out: great for cloud housekeeping, disastrous when HR, Legal, or auditors ask for proof from last year and your logs are empty. In the episode, we walk through how to check your real retention window, why screenshots don’t count as evidence, and how to move from trusting ephemeral run logs to writing structured approval records (dates, decisions, actors) into durable stores like Dataverse, SharePoint, or SQL that you actually control.

DESIGNING APPROVAL FLOWS THAT DON’T COLLAPSE

https://www.spreaker.com/cms/episodes/67846983/edit/info?filter=NETWORK&network=18613266Most approval flows implode because they’re built as thin demos: single‑stage, hard‑coded emails, no state tracking, no restart concept. That works until org structure changes, people leave, or departments demand different rules—then your flow becomes a brittle monster of nested conditions nobody wants to touch. We show how to design for reality instead: store roles instead of individual addresses, look up approvers dynamically from AD, SharePoint, or Dataverse, and keep a persistent “stage” field so you can restart at the correct step without resending the whole process. The result is a modular, restartable approval engine that survives staff changes, rule updates, and errors without forcing you to rebuild from scratch.

ESCALATIONS AND REMINDERS WITHOUT THE SPAM STORM

https://www.spreaker.com/cms/episodes/67846983/edit/info?filter=NETWORK&network=18613266Bad flows solve stuck approvals with brute force: wave after wave of reminder emails until people start ignoring everything from “Flow Notifications.” We unpack how to replace spam cannons with sane escalation logic—time‑based reminders with clear limits, reassignment rules when someone is away, and escalation paths that go to the right roles instead of everyone in CC. You’ll learn how to use persistent state and logging so you always know where a request is, who’s blocking it, and how to nudge or re‑route it without drowning inboxes.

WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67846983/edit/info?filter=NETWORK&network=18613266

• Why Power Automate run history is temporary debugging, not an audit trail you can rely on.
• How to design permanent approval logs in Dataverse, SharePoint, or SQL with structured fields.
• How to build multi‑stage, restartable approvals using state tracking instead of one‑off flows.
• How to replace hard‑coded approver emails with dynamic, role‑based lookups.
• How to implement escalations and reminders that keep work moving without creating notification fatigue.

THE CORE INSIGHT

https://www.spreaker.com/cms/episodes/67846983/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that if you rely on default run history, you don’t have an approval record at all—just a temporary trace that disappears on Microsoft’s schedule, not yours. Once you treat logging, state, and role management as first‑class design elements, your Power Automate approvals become restartable, auditable workflows instead of fragile black boxes that crumble the moment someone asks, “Can you prove this was actually approved?”

https://www.spreaker.com/cms/episodes/67846983/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67846983/edit/info?filter=NETWORK&network=18613266

• Power Automate admins and makers responsible for business‑critical approvals.
• Compliance, risk, and audit teams who rely on workflow records as evidence.
• IT and process owners upgrading “V1 demo flows” into production‑grade approval systems.
• Architects and consultants designing governance patterns for Power Platform workflows.

ABOUT THE AUTHOR / HOST

https://www.spreaker.com/cms/episodes/67846983/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365 and Power Platform consultant and host of the M365.FM podcast, helping organizations treat Microsoft 365, Power Automate, and Dataverse as one integrated operating system instead of a patchwork of fragile, unlogged flows. He works with teams running on Microsoft 365 and Azure to design approval architectures, logging strategies, and governance so that workflows are restartable, auditable, and resilient instead of disappearing the moment run history rolls off.

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

Most organizations quietly assume Copilot is under‑used—not because people hate it, but because the dashboards leadership is staring at are counting the wrong thing. In this episode, we walk through the “gym card swipe” problem: Entra and app sign‑in charts look impressive in a slide deck, yet they only prove that people opened Word or Teams, not that anyone actually used prompts to get work done. You’ll see how that mismatch between identity telemetry and real Copilot behavior fuels the narrative that “nobody uses it,” and how to flip the script by pulling the right usage signals, telling the story in CFO‑ready language, and targeting adoption where the data proves Copilot already helps.https://www.spreaker.com/cms/episodes/67842319/edit/info?filter=NETWORK&network=18613266

THE CFO’S REPORT DOESN’T LIE – BUT IT’S NOT THE FULL TRUTH

https://www.spreaker.com/cms/episodes/67842319/edit/info?filter=NETWORK&network=18613266We start with the classic scene: a CFO storms in waving an admin report that says “low Copilot adoption” and demands to know why the spend was approved. The chart isn’t fake, it’s just incomplete—showing app sign‑ins, not Copilot actions. You’ll learn how to explain, in one leadership‑friendly sentence, why a graph of Word sign‑ins is like counting gym check‑ins instead of workouts, and how to defend your rollout without hand‑waving: “sign‑ins show who opened the app; Copilot adoption means prompts and actions, which live in different telemetry.” From there, we outline a concrete plan: verify which Copilot usage reports your tenant actually exposes, enable or request the right Insights where needed, and prep a simple side‑by‑side view—door counts vs real Copilot actions—that resets the conversation from “no one uses this” to “here’s where it actually helps today.”

ENTRA VS INSIGHTS: TWO DASHBOARDS, TWO STORIES

https://www.spreaker.com/cms/episodes/67842319/edit/info?filter=NETWORK&network=18613266Next, we dissect the “two dashboards” problem that quietly wrecks most adoption slides. Entra (and similar identity views) is brilliant at what it does: tracking who signed in, from where, and on which app—but it is not designed to tell a Copilot ROI story. Insights, by contrast, is where you start seeing behavior: prompt counts, app‑level Copilot activity, and sometimes department‑level patterns depending on your tenant configuration. We walk you through a practical three‑step workflow: confirm which Copilot/Insights telemetry you can see with your admin role, identify at least three dimensions (app, usage volume, department), and build anonymized, aggregated views that leadership can trust without turning adoption reporting into a privacy nightmare. The goal: stop treating door‑logs as productivity metrics and start using behavior data to decide where to invest training and enablement.https://www.spreaker.com/cms/episodes/67842319/edit/info?filter=NETWORK&network=18613266

WHERE COPILOT CLICKS ACTUALLY HAPPEN

https://www.spreaker.com/cms/episodes/67842319/edit/info?filter=NETWORK&network=18613266Marketing demos love to show Copilot rewriting entire strategies in PowerPoint, but real usage patterns are much more grounded. In many tenants, Copilot activity clusters in Outlook, Teams, and Word—places where people already spend their day cleaning up emails, writing updates, and fixing phrasing under time pressure. We explain why these “small win” scenarios drive sticky adoption: low risk, high repetition, and immediate payoff. Your job is to validate that pattern against your own tenant—look at which apps show actual Copilot actions, then start enablement there instead of pushing generic, all‑apps training. That shift lets you tailor stories and examples to where people already click, turning Copilot from a theoretical platform feature into something that quietly saves time in the tools they live in.https://www.spreaker.com/cms/episodes/67842319/edit/info?filter=NETWORK&network=18613266

WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67842319/edit/info?filter=NETWORK&network=18613266

• Why leadership‑facing admin charts often mislabel sign‑ins as “Copilot adoption.”
• How to explain, in plain language, why Entra sign‑in data is a door counter, not a usage log.
• How to check whether your tenant exposes Copilot Insights or similar behavioral telemetry.
• How to build side‑by‑side views that compare app sign‑ins vs prompt‑level Copilot activity.
• How to identify which apps (Outlook, Teams, Word, etc.) actually drive Copilot value in your environment and focus enablement there.

THE CORE INSIGHT

https://www.spreaker.com/cms/episodes/67842319/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that Copilot isn’t “useless”—your telemetry storytelling might be. As long as leadership only sees identity‑level charts, they’ll assume Copilot is an expensive treadmill nobody runs on; once you surface real prompt and action data, app‑by‑app, you can show where Copilot already changes workflows, where it stalls, and what to fix next. That’s how you move the conversation from defending a license line item to co‑designing a roadmap based on evidence.

https://www.spreaker.com/cms/episodes/67842319/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67842319/edit/info?filter=NETWORK&network=18613266

• Microsoft 365 and Copilot admins under pressure to “prove” adoption and ROI.
• CIOs, CFOs, and IT leaders reading conflicting Copilot reports and dashboards.
• Analytics and BI teams responsible for surfacing Copilot telemetry to leadership.
• Change and enablement leads designing targeted Copilot training and champions programs.

ABOUT THE AUTHOR / HOST

https://www.spreaker.com/cms/episodes/67842319/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365 and AI governance consultant and host of the M365.FM podcast, helping organizations treat Microsoft 365, Copilot, and their telemetry as one integrated operating system instead of a mess of dashboards nobody trusts. He works with teams running on Microsoft 365 and Azure to design data‑driven Copilot rollouts—tying licensing, usage, and business outcomes together so conversations with leadership are grounded in real signals, not wishful graphs.

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

You know what’s truly horrifying? A Power BI gateway that works flawlessly in your test tenant—green checks everywhere, dashboards refreshing like a dream—then completely collapses in production because the one outbound firewall rule that actually matters was never opened. In this episode, I break down the real communication architecture of the gateway, how test tenants lull you into a false sense of security, and why passing a single portal connectivity test means almost nothing once packets start hitting your corporate firewall. You’ll learn the exact diagnostics path that cost me a full weekend and two gallons of coffee—from vague “connection failure” logs and misleading green checks to the moment we finally realized outbound filtering and missing FQDN whitelisting were quietly choking Service Bus traffic in production.https://www.spreaker.com/cms/episodes/67835305/edit/info?filter=NETWORK&network=18613266

THE SETUP THAT LOOKED SIMPLE… UNTIL IT WASN’T

https://www.spreaker.com/cms/episodes/67835305/edit/info?filter=NETWORK&network=18613266On paper, our plan was textbook: one dedicated gateway server, supported OS, patched, standard firewall ports opened, validate against a test tenant, then flip to production. The wizard made it look like a “next, next, finish” job, and for a few dangerous hours that illusion held—connection tests passed, reports refreshed, and we muttered, “Why does everyone complain about gateways?” The moment we switched to the real tenant, everything cracked: executive dashboards failed in the middle of morning meetings, red error banners replaced numbers, and an avalanche of tickets, calls, and emails followed. The logs were the worst part—vague, fortune‑cookie‑style messages about “connection failures” that pointed us everywhere and nowhere at once, while documentation insisted we had done everything right. That’s when the painful truth hit: passing a single connectivity test only proves one handshake worked once; it doesn’t mean your network design can sustain real‑world gateway traffic.https://www.spreaker.com/cms/episodes/67835305/edit/info?filter=NETWORK&network=18613266

THE FIREWALL RULE NOBODY TALKS ABOUT

https://www.spreaker.com/cms/episodes/67835305/edit/info?filter=NETWORK&network=18613266The real culprit turned out not to be server config, patches, or even inbound rules—it was outbound filtering. Our test environment had relaxed outbound controls, so the gateway happily reached Azure Service Bus and other dependencies; production, locked down with strict outbound rules, simply dropped those calls. The evidence only surfaced after we dug through firewall logs, temporarily opened outbound traffic in a maintenance window, and watched everything spring back to life—proving the app wasn’t broken, the network was. From there, packet captures and DNS traces revealed what should have been obvious all along: we needed controlled outbound access based on FQDN whitelisting instead of fragile, ever‑changing IP ranges. Once we added the right FQDNs for gateway services and adjusted the outbound rules, the constant Service Bus errors vanished, refreshes stabilized, and the “random” failures stopped cold. That’s the part most guides skip: if you treat gateway networking like a one‑time port‑opening exercise instead of an ongoing design problem, test will lie to you and production will punch you in the face.

WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67835305/edit/info?filter=NETWORK&network=18613266

• Why a Power BI gateway can pass every test in your lab and still fail spectacularly in production.
• How misleading green checks in the portal create a false sense of security about your gateway setup.
• How to recognize when vague “connection failure” logs actually point to outbound firewall filtering.
• How to use firewall logs, temporary opens, packet captures, and DNS traces to prove it’s the network, not the gateway.
• Why FQDN‑based whitelisting is critical for stable gateway communication to Azure services.

THE CORE INSIGHT

https://www.spreaker.com/cms/episodes/67835305/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that Power BI gateway outages in production rarely come from a single missed checkbox—they come from misunderstanding how the gateway talks across your network. Until you design outbound access and FQDN whitelisting as deliberately as you choose the server and install the software, every green check in test is just a mirage—and the real horror story is waiting for you in production.

https://www.spreaker.com/cms/episodes/67835305/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67835305/edit/info?filter=NETWORK&network=18613266

• Power BI and gateway admins responsible for on‑premises data connectivity.
• Network and security engineers who have to reconcile strict firewall policies with working gateways.
• Architects and platform owners designing hybrid data access between on‑prem systems and Power BI.
• Consultants and in‑house teams who never want to lose another weekend to mysterious gateway failures.

ABOUT THE AUTHOR / HOST

https://www.spreaker.com/cms/episodes/67835305/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365 and data platform consultant and host of the M365.FM podcast, helping organizations treat Microsoft 365, Power BI, and their hybrid connectivity as one integrated operating system instead of a pile of fragile, undocumented links. He works with teams running on Microsoft 365, Azure, and on‑prem data sources to design gateway architectures, firewall configurations, and troubleshooting playbooks that keep reports online—even when the network fights back.

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

Let’s be real—Teams channels are just three kinds of roommates. Standard channels are the open‑door living room, Private channels are the locked bedroom, and Shared channels are when your roommate’s cousin “stays for a few weeks” and suddenly your fridge looks like a crime scene. The problem isn’t the labels, it’s treating all three like the same thing: by the end of this episode, you’ll know exactly which channel type to use for marketing, dev, and external vendors—without accidentally leaking sensitive files or building silos nobody can see into. We unpack what really happens under the hood in Microsoft 365 when you pick Standard, Private, or Shared, why that choice sets your security perimeter and file visibility for the entire project, and how a simple channel playbook at kickoff can save you from governance drama and “please delete that file” emails later.

WHY PICKING THE WRONG CHANNEL WRECKS YOUR PROJECT

https://www.spreaker.com/cms/episodes/67832118/edit/info?filter=NETWORK&network=18613266Channel choice isn’t cosmetic—it’s who can see what, by design. Use a Standard channel when only a subset should see the content and you’ve just handed interns, externals, or the wrong department a front‑row seat to things they shouldn’t touch, from financial forecasts to raw builds. In this episode, we walk through real‑world failures: product launches where marketing and dev shared a Standard channel and accidentally exposed embargoed press kits to people who only needed bug lists, or leadership chats that landed in the same space as junior staff updates. You’ll learn a simple rule set: Standard when every Team member truly needs visibility, Private when only an inner circle should see the conversation and files, and Shared when you bring in external partners who must collaborate without getting the full house key.

STANDARD, PRIVATE, SHARED – CUTTING THE MARKETING FLUFF

https://www.spreaker.com/cms/episodes/67832118/edit/info?filter=NETWORK&network=18613266Microsoft loves calling every channel a “collaboration space,” but under the hood they’re three different security and storage models wearing the same UI. Standard channels use the parent Team’s SharePoint site and are visible to every member of the Team—perfect for broad project chatter and shared artefacts, dangerous for anything confidential. Private channels restrict membership to a subset of the Team and back their files with a separate SharePoint site, so only invited members even see that channel exists—ideal for finance, HR, or leadership work inside a bigger Team. Shared channels are designed for cross‑Team and external collaboration: they give partners or other internal Teams access to a single channel (often with its own backing site) without adding them to the entire Team, so vendors and clients can join the conversation without roaming through the rest of your workspace. Once you map “what it is, where files live, who sees it, when to use it” for each type, channel choice stops being guesswork and starts being a deliberate part of your security model.

PICKING THE RIGHT CHANNEL WITHOUT GETTING BURNED

https://www.spreaker.com/cms/episodes/67832118/edit/info?filter=NETWORK&network=18613266The real fix is to stop letting anyone spawn channels on instinct and start treating channel creation as a governance decision. We give you a practical playbook: during project kickoff, decide the audience first, then match it to Standard/Private/Shared using a simple grid, and restrict who is allowed to create new channels so you don’t end up with a sprawl of random Standards leaking files and ghost Private channels no one remembers owning. You’ll hear concrete patterns for typical scenarios—cross‑department projects, vendor workspaces, leadership areas—and a three‑step test (who should see it, what files land there, what happens if someone leaves) you can run before clicking “Create.” Done right, your channels turn from accidental leak vectors into clear containers that match how your organization actually works.

WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67832118/edit/info?filter=NETWORK&network=18613266

• Why treating Standard, Private, and Shared channels as identical quietly causes leaks and confusion.
• How channel type maps to storage (SharePoint backing), membership, and visibility in Microsoft 365.
• A simple rule set to choose the right channel for marketing, dev, leadership, and external vendors.
• How to add basic governance—who can create channels, when to decide the type, and how to avoid channel sprawl.
• Practical project scenarios where the wrong channel sunk trust, and how to avoid repeating them.

THE CORE INSIGHT

https://www.spreaker.com/cms/episodes/67832118/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that a Teams channel is not “just a conversation,” it’s a security and storage boundary that decides who sees your files for the entire life of a project. Once you stop clicking “new channel” like a vending machine button and start applying a simple decision framework—Standard for full‑Team transparency, Private for inner circles, Shared for external and cross‑Team work—you dramatically cut oversharing risk, cleanup drama, and late‑stage governance firefighting.

https://www.spreaker.com/cms/episodes/67832118/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67832118/edit/info?filter=NETWORK&network=18613266

• Teams owners and project leads who create and manage channels for real projects.
• Microsoft 365 and security admins trying to reduce accidental oversharing and channel sprawl.
• Governance and compliance teams designing safer collaboration patterns in Teams.
• Power users and champions who want a simple, teachable way to pick the right channel every time.

ABOUT THE AUTHOR / HOST

https://www.spreaker.com/cms/episodes/67832118/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365 consultant and host of the M365.FM podcast, helping organizations treat Teams, SharePoint, and Entra ID as one integrated operating system instead of a patchwork of random channels and sites. He works with teams running on Microsoft 365 and Azure to design channel strategies, permission models, and governance playbooks so collaboration stays fast and flexible without leaking sensitive content to the wrong audience.

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