M365 Show Podcast

Mirko Peters

Welcome to the M365 Show — your essential podcast for everything Microsoft 365, Azure, and beyond. Join us as we explore the latest developments across Power BI, Power Platform, Microsoft Teams, Viva, Fabric, Purview, Security, and the entire Microsoft ecosystem. Each episode delivers expert insights, real-world use cases, best practices, and interviews with industry leaders to help you stay ahead in the fast-moving world of cloud, collaboration, and data innovation. Whether you're an IT professional, business leader, developer, or data enthusiast, the M365 Show brings the knowledge, trends, and strategies you need to thrive in the modern digital workplace. Tune in, level up, and make the most of everything Microsoft has to offer. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support.

  1. Stop Fixing Legacy Java: The AI That Does It For You

    -5 H

    Stop Fixing Legacy Java: The AI That Does It For You

    Stop Fixing Legacy Java—Let the AI Do ItStill hand-upgrading legacy Java? That’s not craftsmanship; that’s unpaid penance. Manual modernization is a failure mode—slow, error-prone, and permanently behind. The truth? AI agents now handle the drudgery with receipts.Here’s what you actually get: time back, CVEs gone, and cloud bills that stop bleeding. We’ll walk a narrative case study—stack, benchmarks, results—plus a full audit trail so governance can breathe. There’s one metric that embarrassed finance and delighted security—stay for that. Now, here’s what happens when you let Copilot App Modernization drive.Case Setup: The Legacy Stack and the Modernization MandateBaseline first. We’re dealing with a Java 8-era Spring application—classic MVC plus a sprinkle of scheduled jobs—built with Maven, running on AWS. Conservative governance, noisy alerts, everyone swears the app is “stable” while PagerDuty begs to differ. The stack has drift: parent POMs forked years ago, dependency versions pinned like insect specimens, and a CI pipeline that only passes if you chant. Average user behavior? Ignore the red badges, silence the scanner, and pray the next sprint includes “tech debt.” Spoiler: it never does.Pain inventory. Version drift means modern libraries won’t resolve without exclusions. Dependency hell: transitive roulette where one logging upgrade detonates your HTTP client. Unpatched CVEs sit there, politely waiting for an exploit kit. Idle compute waste? Autoscaling that never scales down, instances at 8% CPU while finance funds a space heater. Add brittle configs: environment variables baked into user data, stateful file writes on disk, and secrets living where secrets shouldn’t live.Constraint: this is audio-only. No performative heroics, no live tab-switching to Stack Overflow. We rely on reproducible artifacts—reports, commit diffs, scanner outputs. Because guesswork is not a strategy, and “worked on my laptop” isn’t evidence.Why Java 21. Virtual threads change concurrency from a scarce resource to a commodity. Thousands of lightweight threads with minimal overhead; throughput goes up, tail latency comes down. Garbage collection improvements—G1 and ZGC refinements—reduce pause times. The Foreign Function and Memory API is stable, which matters if you’re calling native code or wrestling with off-heap buffers. Net effect: measurable performance and maintainability gains. Most people think upgrading is cosmetic. Incorrect. You get cheaper concurrency and fewer stalls—directly visible in service-level graphs.Migration scope: AWS out, Azure in. Align with enterprise standards, consolidate billing, and plug into the platform your identity, policy, and observability already inhabit. We’ll target Azure App Service or Azure Spring Apps depending on the workload profile—simple app, App Service is fine; Spring-heavy microservices with scaling nuance, consider Azure Spring Apps. For data, the mandate is Azure SQL Database; yes, you can keep PostgreSQL on Azure, but the business wants consolidation, so we’ll map the path and show the trade-offs.Governance stance: every action lands in Git. Diffable, reversible, attributable. The agent generates a plan, opens issues, and proposes commits. You approve. It resolves builds, patches dependencies, applies code transformations using known recipes, regenerates the SBOM, and reruns scanners. If something doesn’t pass, it loops—no alt-tab pilgrimage. And when it can’t proceed, it asks for input and documents why. See the difference? Work becomes auditable instead of anecdotal.Before you let an agent touch anything, you assess. Automated inventory across modules, dependencies, build plugins, and runtime configs. Risk-ranked findings with references to advisories and documentation. Cloud readiness flags for service bindings, environment variables, and stateful traps that break when containers come and go. Cost baselines: compute hours, idle percentages, and the egress patterns that finance pretends not to notice until month-end.You might be thinking, “We can triage that by hand.” Fascinating. And you’re still surprised the app crashes. The average user misses the long-tail issues—deprecated APIs deep in the scheduler, a logging bridge masking duplicate class conflicts, or that one library pin that blocks everything from moving. The agent doesn’t miss them because it doesn’t get bored.So the modernization mandate is simple and final: upgrade to Java 21, eliminate CVEs, containerize, migrate to Azure, wire CI/CD with controlled rollouts, enforce policy via approvals and Key Vault, and cut cost without cutting reliability. All changes trace back to commits with rationale. No black box. No swaggering hero-commits at 2 a.m.Assessment first—because guesswork is not a strategy. Then we execute.Assessment: The AI Exposes Technical Debt with ReceiptsHere’s what actually happens when you press assess. The agent doesn’t “scan.” It inventories—code, build files, plugins, transitive dependencies, Docker bits, environment variables, startup scripts, even those stray shell wrappers someone copy-pasted in 2017. It builds a dependency graph, annotates it with CVE data, and ranks risk. Not vibes—severity, exploitability, reachability. It’s the Windows Registry of your app’s reality. Not just a list—your structural spine, exposed.The truth? Most people think they know their stack. They don’t. The agent finds the forked parent POM with a logging version pin that blocks every downstream patch. It flags duplicated SLF4J bridges that shadow each other like feuding roommates. It catches the servlet container that’s quietly three releases behind because your CI only tests the happy path. And yes, it maps deprecated APIs you’ve been calling for years because nobody wanted to touch the job scheduler. Spoiler alert: you’re touching it now.CVEs next. Severity breakdown, affected libraries, and references to advisories—direct links, not rumors. Critical and high get top billing, but it also identifies whether the vulnerable code paths are reachable by your application. Reachability matters. If a transitive library has an issue but your code never calls the vulnerable class, it’s still flagged, but the agent prioritizes fixes that reduce real risk first. You get the remediation options: bump versions, add exclusions, or swap artifacts entirely. That’s a menu, not a mystery.Upgrade readiness comes with receipts. Java 21 requires you to stop pretending it’s 2009. The agent runs OpenRewrite recipes against your codebase in dry-run mode, showing exactly which APIs are deprecated, which imports must change, and where behavior shifts lurk. It calls out illegal reflective access, j.u.c. quirks, and the tiny landmines waiting in XML configuration. It notes frameworks that are ready—Spring versions, plugin compatibility—and those that need coercion. No hand-waving. Every proposed change links back to docs and migration notes.Cloud readiness is where your infrastructure sins go to be cataloged. The agent identifies stateful traps: writing temp files to local disk during requests, caching sessions in memory across instances, storing secrets in a text file under /opt because someone “needed it to work.” It flags environment variable usage that assumes EC2 metadata patterns. It points out service bindings for Redis, queues, and databases that won’t survive container churn. Then it proposes bindings the Azure way: connection strings moved to configuration, Key Vault for secrets, managed identities for auth. You know, like adults.Now the finance shocker: cost baselines. The agent pulls compute hours, instance sizes, scale patterns, and idle percentages from telemetry and infra definitions. It estimates egress costs based on outbound patterns—yes, that one noisy batch job that hurls data across regions every night gets a line item. It translates all of this into a monthly number that doesn’t care about your anecdotes. This is the number that embarrassed finance and delighted security. Why? Because eliminating CVEs while cutting spend is the only religion both teams share.Artifacts or it didn’t happen. The agent produces a plan file with sections: CVE remediation steps, Java upgrade recipes, build changes, code transformations, containerization moves, and cloud target mappings. It opens issues per workstream, tags owners if you want, and scaffolds commits in a separate branch—clean, small diffs with rationales in the messages. SBOM generated, signed, and versioned. Vulnerability scanner outputs attached. That’s audit-ready from step zero.You want traceability? Every finding links to an advisory or a source document: NVD entries, project release notes, OpenRewrite recipe documentation, Azure migration guides. When it suggests replacing a library, it cites compatibility matrices. When it recommends moving a secret, it points to platform guidance on Key Vault and managed identities. It’s not just “because AI said so.” It’s “because this standard, right here, says so.”Controls remain human. The plan sits in Git, awaiting approval. You can adjust priorities, reject a remediation strategy, or demand a different target service—Azure App Service versus Azure Spring Apps—with the trade-offs listed plainly. The agent adapts, reruns the assessment delta, and updates artifacts. No sulking.Once you see the receipts, the posture changes. You stop debating if modernization is “worth it” and start sequencing the work. And yes, the average user will still try to ship a feature first. Fascinating. Meanwhile, the agent has already mapped the shortest path to a secure, compliant, cheaper runtime. Approve the plan. Then watch it do the work you keep postponing.Automated Upgrade: From Java 8 to Java 21 Without the DramaPlan approved, so the agent stops talking and starts doing. The loop is simpl

    21 min
  2. The Secret Architecture That Makes AI Agents Actually Work

    -17 H

    The Secret Architecture That Makes AI Agents Actually Work

    Most people think AI agents fail because of weak prompts. Not true. Prompts guide reasoning—but executors, validation, and workflow graphs are what guarantee reliability. In this episode, we reveal the architecture behind stable, predictable, enterprise-ready AI agents using Microsoft 365 Graph, Azure OpenAI, and Copilot Studio. You’ll learn why traditional prompt-only agents hallucinate tools, break policies, and silently fail—and how a contract-first, validator-enforced architecture fixes accuracy, latency, cost, and auditability. This is the mental model and blueprint every AI builder should have started with. What You’ll Learn 1. Why Prompts Fail at Real-World Operations The difference between cognition (LLMs) and operations (executors)Why models hallucinate tools and ignore preconditionsHow executors enforce idempotency, postconditions, and error recoveryThe “silent partial” problem that breaks enterprise workflows2. Workflow Graphs: The Map AI Agents Actually Need Nodes, edges, state, and explicit control flowWhy DAGs (directed acyclic graphs) dominate reliable workflowsState isolation: persistent vs ephemeral vs derivedCompensations and rollback logic for real-world side effectsMemory boundaries to prevent cross-session leakage3. Secure-by-Design: Validation That Stops Chaos Static graph validation: cycles, unreachable nodes, contract checksRuntime policy checks: RBAC, ABAC, allowlists, token scopesInput/output sanitization to prevent prompt injectionSandboxing, segmentation, and safe egress controlsImmutable logging and node-level tracing for auditability4. Microsoft Integration: M365 Graph + Azure OpenAI + Copilot Studio Least-privilege Graph access with selective fields and delta queriesChunking, provenance, and citation enforcementAzure OpenAI as a reasoning layer with schema-bound outputsCopilot Studio for orchestration, human checkpoints, and approvalsReliable execution using idempotency keys, retries, and validation gates5. Before/After Metrics: The Proof Higher factual accuracy due to citation-verified groundingLower p95 latency via parallel nodes + early exitReduced token cost from selective context and structured plansDramatic drop in admin overhead through traceability and observabilityStable first-pass completion rates with fewer human rescues6. The One Gate That Prevents Dumb Agent Mistakes The pre-execution contract check:Capability matchPolicy compliancePostcondition feasibilityDeny-with-reason paths that provide safe alternativesPreventing privilege escalation, data leaks, and invalid actionsKey Takeaways Prompts are thoughts. Executors are actions. Validation is safety.Reliable AI agents require architecture—not vibes.Graph validation, policy enforcement, and idempotent execution turn “smart” into safe + correct.Grounding with Microsoft Graph and Azure OpenAI citations ensures accuracy you can audit.A single contract gate prevents 90% of catastrophic agent failures. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support. Follow us on: LInkedIn Substack

    27 min
  3. Stop Building Dumb Copilots: Why Context Engineering Is Your Only Fix

    -1 J

    Stop Building Dumb Copilots: Why Context Engineering Is Your Only Fix

    In this episode, we break down the real reason most Copilots fail inside the Power Platform: context debt. Your model isn’t hallucinating because it’s dumb—it’s guessing because you starved it. We walk through a complete, repeatable context engineering blueprint for Copilot Studio and Power Automate, designed to eliminate hallucinations, reduce cross-tenant drift, and dramatically cut latency and cost. You’ll learn how to build the four-layer spine every enterprise Copilot needs: System Context, Retrieval, Tools, and Policies—plus the missing governance layer most teams overlook. What You’ll Learn 1. Why Your Copilot Fails (Context Debt) How missing system rules and vague identity cause inconsistent answersWhy ungrounded Dataverse data leads to hallucinated fieldsThe hidden impact of undefined tools and cross-environment driftHow governance gaps create policy violations and compliance risks2. Layer 1 — System Context That Doesn’t Drift The System Message pattern used in real enterprise deploymentsIdentity, scope, refusal policy, schema awareness, and logging rulesHow to parameterize system context across Dev/UAT/ProdThe “six-line” system message formula that stops ambiguity cold3. Layer 2 — Retrieval That Grounds to Dataverse How to build a Dataverse-first schema indexWhy PDFs and document libraries aren’t grounding—and how to fix themChunking, security trimming, hybrid search, and caching for speedThe schema grounding checklist every agent needs4. Layer 3 — Tooling + Policy Enforcement Turning Power Automate flows into safe, least-privilege “agent verbs”How to encode preconditions, sensitivity flags, and refusal logicUsing DLP, Conditional Access, Purview, and MIP labels to prevent driftWhy you need an admin kill-switch (and how to add one)5. End-to-End Build (With Before/After Metrics) Step-by-step Copilot Studio + Power Automate buildSchema indexing, tool catalog, prompt wrappers, and environment bindingsBefore/after metrics: latency, token usage, hallucinations, policy adherenceReal example: correcting an invalid “fast-track to approved” requestKey Takeaways Models don’t provide truth—they only predict text. You provide the truth.The four layers—System, Retrieval, Tools, Policies—eliminate drift and hallucination.Dataverse schema is the spine; documents are secondary.Governance isn’t optional: DLP, Conditional Access, and sensitivity labels define reality.A fully engineered context cuts latency, costs, hallucinations, and audit risk. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support. Follow us on: LInkedIn Substack

    24 min
  4. The 1400 Connector Lie: Why Azure Logic Apps Beats Power Automate

    -1 J

    The 1400 Connector Lie: Why Azure Logic Apps Beats Power Automate

    Most teams assume that more connectors = more power. Microsoft markets “1,400+ connectors” as a universal automation buffet—but in the real world, that’s a vanity metric, not an architectural advantage. In this episode, we break down why Azure Logic Apps consistently outperforms Power Automate in enterprise scenarios that require: VNet-secured hybrid connectivityHigh-volume API orchestrationAzure Monitor + App Insights observabilityRBAC and Azure Policy-controlled governanceAI agents backed by Azure FunctionsScalable architectures with predictable costIf you’ve ever hit throttling limits, struggled with the On-Premises Data Gateway, or watched a flow fail silently during a critical batch window, this is your corrective lens. This is NOT a “Power Automate bad” rant. It’s a responsible architecture conversation that separates citizen automation from mission-critical integration. 🎯 What You’ll Learn (High-Ranking SEO Keywords Included) 1️⃣ Why “1,400+ Connectors” Is Misleading We explain why connector count doesn’t equal capability—because throttling ceilings, maker-owned connections, and tenant-wide action limits create fragility at scale. 2️⃣ Power Automate vs Logic Apps — Execution Models Explained You’ll learn the functional differences between: Power Automate Cloud Flows (stateful only)Logic Apps ConsumptionLogic Apps Standard (dedicated compute, scale-out, stateless/stateful choices)This helps teams decide which platform fits automation, integration, batch workloads, or microservices orchestration. 3️⃣ VNet Integration, Private Endpoints & Azure Arc We show why network boundaries and identity isolation make Logic Apps the correct choice for enterprises with: FirewallsOn-prem SQLSAPLegacy APIsSensitive workloadsRegulatory compliance4️⃣ High-Throughput API Workloads We run side-by-side evaluations of: ThroughputLatency under load (p95/p99)Concurrent fan-out/fan-in operationsDead-letter patternsDeterministic retriesThis is where the differences between tenant throttles and dedicated compute become most obvious. 5️⃣ Azure Monitor + App Insights Tracing You’ll see examples of: Dependency mapsCorrelation IDsCross-service observabilityMetrics dashboardsRun-history patternsAlert rules with actionable contextPerfect for teams who need auditable, explainable automation. 6️⃣ When Power Automate Is the Right Tool We define the boundaries where Power Automate is ideal: M365 approvalsNotificationsTeam automationsLightweight workflowsCitizen developmentNon-regulated business processes7️⃣ AI Agents With Azure Functions We explore the real-world pattern for modern AI automation: Agent ≠ app. Agent = orchestration + tools. Logic Apps handles the orchestration. Azure Functions handles the compute. Power Automate cannot fill that role reliably under load. 🧪 The Three Enterprise Scenarios We Tested Scenario 1 — Hybrid On-Prem Access With VNets & Arc Power Automate gateway vs Private EndpointsManaged identity vs maker-owned connectionsHow Logic Apps prevents token driftAzure Policy for “no public endpoints”Arc-enabled Kubernetes hosting the runtime on-premScenario 2 — High-Volume API Orchestration Bursty workloadsMassive fan-outStateful vs stateless pipelinesCircuit breakers, DLQs, backpressureAPI tiering & concurrency controlsScenario 3 — AI Agent + Azure Functions When connectors failPolicy logic beyond dropdownsRunning custom code under identityVector lookups, payload normalizationObservability across agent → workflow → function → connector🏗 Full Decision Framework (SEO-Targeted) Choose Power Automate when: Workloads are smallMostly M365 integrationApprovals and notificationsCitizen developers are the ownersNo VNet or hybrid data needsAudit requirements are minimalChoose Azure Logic Apps when: You need VNet, Private Endpoints, or hybrid/on-prem connectivityYou need to process 100k+ actions per 5 minutesObservability matters (App Insights)Governance matters (RBAC, Azure Policy)AI agents need real compute (Functions)You require stateless high-throughput executionSLAs are contractually enforcedThrottles would cause financial or operational damage🔐 Governance, Security & Compliance Highlights Logic Apps uses managed identities, not user-bound tokensAzure Policy enforces guardrails automaticallyRBAC scopes access granularlyApp Insights + Monitor enable real-time detection & tracingDead-letter queues prevent silent failuresVNet & Arc satisfy strict data residency requirementsThese features matter for industries like: Financial services, healthcare, government, manufacturing, energy, HRIS, and global enterprises. 💸 Cost Behavior at Scale You’ll learn the true cost model differences: Power Automate: per-flow/per-user licensing + throttling costsLogic Apps: consumption + dedicated compute + scale-out optionsFor high-volume workloads, Logic Apps is dramatically cheaper and more predictable. 📌 Final Takeaway Connector count is marketing. Architecture determines survivability. Power Automate is perfect for team workflows. Logic Apps is built for the enterprise spine. If you run hybrid systems, regulated workloads, or high-volume APIs—you choose Logic Apps, or you choose incidents. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support. Follow us on: LInkedIn Substack

    24 min
  5. Power Automate Is Dead: The AI Workflows Agent That Replaced Your Job

    -2 J

    Power Automate Is Dead: The AI Workflows Agent That Replaced Your Job

    Power Automate has dominated Microsoft 365 automation for years—but everything just changed. In this episode, we break down the disruptive rise of Workflows Agent, the AI-driven automation engine inside Microsoft 365 Copilot that can replace entire categories of traditional cloud flows. While Power Automate remains the enterprise-grade backbone for long-running, multi-branch, highly governed workflows, Workflows Agent delivers something radically different: conversational, intent-driven automation that builds and runs tasks in seconds. You’ll learn why “drag-and-drop flows” are becoming legacy for everyday work, how AI automations reduce build time, and when to choose Agent vs Power Automate. Plus, we cover governance, DLP, licensing, and the realities of Frontier features—because none of this matters if you can’t ship automation safely. What Workflows Agent Actually Is (and Isn’t) Workflows Agent isn’t a redesigned Power Automate canvas—it’s a new class of automation entirely. You describe what you want done in natural language, and the Agent composes the steps across Outlook, Teams, SharePoint, Planner, and Microsoft Graph. Think intent → automation, not connector dragging. In this episode, we break down: how Workflows Agent interprets tasks using Microsoft Graph contextthe difference between workflow-based AI and agentic AIwhat the Agent can already automate (emails, Teams posts, SharePoint items, Planner tasks)limits of early-stage Frontier featureswhen the 100-second external call window matterswhere Power Automate still dominates (branching, SLAs, long-running flows, multi-system data orchestration)You’ll walk away understanding the real architecture—not the marketing version. The Real Comparison: Power Automate vs Workflows Agent Power Automate strengths deterministic workflows with explicit logicrich connectors across hundreds of systemslong-running approvals with SLAsdurable retries, exception branches, idempotencydetailed run histories and visual debuggingstrict governance for regulated processesWorkflows Agent strengths builds workflows using natural languagedramatically faster for simple automationsno schema mapping, no GUID hunting, no nested panescontext-aware through Graphperfect for chat-based or email-based user scenariosworks natively inside Microsoft 365 CopilotThis episode explains the real physics: Power Automate wins precision and durability; Workflows Agent wins speed and accessibility. Use Cases: What Happens When AI Takes Over Your Workflow We dive into five real-world comparisons: 1. Approvals Power Automate handles escalations, branching, SLAs, and audit logs. Workflows Agent handles single-approver, everyday approvals in seconds. The speed difference is shocking—and measurable. 2. Data Sync Power Automate is explicit and precise. Workflows Agent is fast for notifications, task creation, and Teams updates. Specify destinations clearly and you avoid misrouting. 3. Incident Triage Agent-driven classification beats handcrafted keyword matrices. Power Automate still wins postmortems, retries, escalations, and strict routing. 4. CRM Updates Agent handles summary + context capture directly from Outlook. Power Automate ensures schema-locked writes, deduping, and compliance. 5. IT Onboarding Agent handles intake and kickoff conversations. Power Automate handles the marathon: licensing, provisioning, long-running approvals. These examples show exactly where each platform wins—and where they fail. Governance & Security: The Part IT Actually Cares About We break down how to govern the Agent so it doesn’t become shadow IT: align Copilot & Power Platform DLP policiesenforce RBAC for who can publish Agent workflowsuse separate dev/test/prod environmentstrack automations in Microsoft 365 admin analyticsdefine retention for conversations and workflow historiestreat prompt text as versioned configuration (because it IS configuration)enforce hybrid patterns for regulated processes (Agent → Power Automate)AI does not excuse you from governance—if anything, it demands stronger guardrails. Licensing: Costs Without the Glitter You’ll learn the honest math: Power Automate: per-user or per-flowWorkflows Agent: message-based, tied to Microsoft 365 CopilotWhen enterprise-scale headless flows are cheaper in Power AutomateWhen chat-based automation makes Workflows Agent practically freeHow hybrid patterns lower total cost of ownershipThis is the licensing explanation that keeps CFOs and IT leaders from arguing in circles. Refactor Plan: What to Keep, Move, or Retire We provide a step-by-step modernization strategy: Keep in Power Automate: long-running, multi-branch logicescalated approvalsintegration spanning multiple systemsregulated workflows with audit requirementstasks requiring retries or rollbackMove to Workflows Agent: simple approvalsquick tasksnotificationsTeams updatesCRM note capturesOutlook → SharePoint → Planner handoffsanything explainable in a single sentenceHybrid Pattern: Agent handles intake, summarization, confirmation → Power Automate performs the durable, auditable, multi-system actions. This is the pattern you’ll use for the next decade. Key Takeaway Power Automate isn’t dead… Your excuses for slow, overly complex workflows are. Workflows Agent covers the everyday work at lightning speed. Power Automate remains the enterprise spine. Together, they form the future of Microsoft 365 automation. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support. Follow us on: LInkedIn Substack

    29 min
  6. The SharePoint Lie That Breaks Every Power App

    -2 J

    The SharePoint Lie That Breaks Every Power App

    Many Power Apps fail for one simple reason: SharePoint Lists are not a database. They’re designed for content and collaboration—not multi-table relationships, delegation, or large-scale filtering. This episode breaks down the architectural mismatch that causes apps to stall at 2,000 records, show incomplete results, and slow to a crawl behind blue delegation banners. You’ll learn why SharePoint becomes unreliable past 5,000 items, how non-delegable formulas silently cap results, and when Dataverse becomes the only platform that can scale. If you’ve struggled with performance, delegation, or governance, this episode will show you exactly why—and how to fix it. Why SharePoint Breaks Power Apps SharePoint is excellent for documents and simple lists, but Power Apps need: server-side filteringrelational data modelingreliable delegationaudit and security controlsSharePoint’s limitations cause: non-delegable queries (Search, OR, multi-column filters)500–2,000 record capsslow galleries and inconsistent resultsfragile lookup modelingperformance drops near the 5,000-item List View ThresholdIn short, SharePoint stores data, but Power Apps can’t query it reliably at scale. Measurable Failure Modes You’ll learn the three signals that your SharePoint-backed app is already in trouble: 1. Delegation Warnings The blue banner isn’t optional—it means Power Apps is filtering client-side and only seeing a fraction of your data. 2. Slow Screen Loads When queries can’t delegate, the client downloads extra data and processes it locally, creating lag and inconsistent results. 3. Record Count Limits Lists can technically hold millions, but Power Apps can’t query them meaningfully once filters stop delegating. Anything past the threshold becomes invisible. Why Dataverse Fixes It Dataverse is built as a true data engine for Power Apps. It offers: full delegation for complex filtersserver-side query executionproper relationships and lookupsrow- and field-level securitybuilt-in auditing and compliancebetter performance with 2025 Power Apps runtime improvementsWith Dataverse, the 2,000-record limit disappears because logic runs on the server where the data lives. Cost Reality: “Free SharePoint” Is Not Free SharePoint seems free, but you pay heavily in: Power Automate workaroundsnon-delegable formula hacksgovernance gapsperformance troubleshootingincomplete results and user mistrustDataverse licensing is predictable; SharePoint workarounds accumulate endlessly. When to Move to Dataverse Use Dataverse when: record counts exceed ~100,000you need multi-column search or compound filtersyou have more than 1–2 lookups per recordoffline/mobile matterssecurity must be granulardelegation banners appear during prototypingIf any of these are true, SharePoint becomes a bottleneck—and an eventual rewrite. Migration Summary A simplified migration path: Map SharePoint lists → Dataverse tables and relationshipsDefine security roles, field-level rules, and auditingClean and load data into Dataverse (parents → children)Replace SharePoint connectors in apps/flowsRewrite non-delegable formulas into delegable patternsPilot, cut over, and retire SharePoint listsKey Takeaway SharePoint Lists are great for content—not as a backend for production Power Apps. Dataverse is the platform that delegates, scales, and governs correctly. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support. Follow us on: LInkedIn Substack

    20 min
  7. The Power Apps Lie: Why Your Excel Data Will Still Fail

    -3 J

    The Power Apps Lie: Why Your Excel Data Will Still Fail

    You clicked “Create app from Excel,” felt clever, and accidentally scaled your chaos. It’s not your fault—Power Apps makes it look easy. But Excel isn’t a database; it’s a calculator wearing a database costume. The moment you try to operationalize spreadsheet data in Power Apps, Dataverse exposes every hidden flaw: missing keys, mixed types, ambiguous relationships, duplicate entities, orphaned rows, and silent corruption spreading behind the scenes. This episode tears down the five failure patterns that silently destroy Power Apps built on Excel data—and then rebuilds your data model correctly. You’ll learn how to fix primary keys, enforce types, replace VLOOKUPs with proper relationships, eliminate multi-purpose columns, and prevent orphaned records so your app stops breaking under its own weight. If you’re tired of inconsistent behavior, failing imports, broken lookups, and unpredictable automations, this episode is your blueprint. What You Will Learn The Real Reason Excel Data Fails in Power Apps We start by breaking down why Excel feels “fine” for small tasks but collapses in Dataverse: No enforced identityNo enforced typesNo referential integrityNo audit trailNo concurrency modelUnlimited ambiguityHidden inconsistencies from copy-paste culture Power Apps expects structure. Excel hides the lack of structure until it’s too late.You’ll discover why your spreadsheet worked yesterday but fails catastrophically when imported into an actual data platform. Failure Pattern #1 — No Primary Keys: The Silent Destroyer Most Excel “tables” are just rows. No identity. No contractual uniqueness. No stable way to know whether a row is the same record as last week. This episode explains: Why surrogate GUIDs must be your primary keysWhy natural keys drift and break historyHow alternate keys allow clean upsertsHow Excel’s “uniqueish” text values lie to youHow missing keys cause duplicates, overwrites, and broken automationsHow to generate stable IDs inside Excel before an importWhy Dataverse’s “Primary Name” column is NOT the primary keyYou’ll learn how to build a correct key strategy and fix your source data so Power Apps stops merging the wrong records or duplicating everything. Failure Pattern #2 — Mixed Data Types: The Spreadsheet Horror Show Excel allows one column to contain: ✔ numbers ✔ text ✔ dates ✔ leftover Outlook pastes ✔ blanks that aren’t real blanks ✔ currency symbols mixed into strings Dataverse does not. It enforces meaning. You’ll learn how to model your data correctly with: Whole Number vs Decimal vs CurrencyBoolean vs ambiguous textDateOnly vs DateTimeText fields with normalizationChoice fields for finite statesLookup fields for referencesWe cover how Power Query can clean, normalize, and coerce types before they ever reach Dataverse, and why ignoring types causes broken formulas, inconsistent logic, and unreliable reports. Failure Pattern #3 — VLOOKUP as “Joins”: The Spreadsheet Illusion Excel users simulate relationships by repeating text values and using VLOOKUP. Dataverse does not: it uses actual relationships. We show why: VLOOKUP duplicates text and drifts easilyOne rename breaks hundreds of dependent rowsLookups bind child records to parent IDs instead of labelsA single change to a parent updates everywhere automaticallyYou should model Suppliers, Locations, Categories as tables—not textYou’ll learn how to replace VLOOKUP with Dataverse lookup columns that prevent duplication, preserve history, and eliminate fragile dependencies. Failure Pattern #4 — Multi-Purpose Columns: Where Spreadsheets Go to Die Excel encourages stuffing anything into one column: StatusNotesCommentsTemporary statesMixed enumerationsFlagsConditions“Just this once” exceptionsPower Apps cannot operate on that ambiguity. This episode explains: Why “Status” should be a ChoiceWhy “Location” should be a LookupWhy notes need their own text columnHow to split overloaded fields into governed valuesHow to map free-text to clean, consistent optionsHow this impacts validation, logic, views, and automationsYou’ll learn how to make your model predictable and eliminate the silent drift that makes reports lie. Failure Pattern #5 — Orphaned Rows: The Most Dangerous Spreadsheet Habit In Excel, you can delete a supplier row without realizing thousands of product rows still reference it. In Dataverse, this creates orphans—records with no parent—which break everything. You’ll learn: Why relationships must be requiredHow to enforce parental integrityWhy delete behavior should usually be “Restrict”How to preload parent entities and resolve lookupsHow to detect & repair orphaned recordsWhy “Unknown Supplier” should be a real row, not a blank valueOrphans ruin reporting, destroy accuracy, and break flows. Dataverse can prevent them—if you model it correctly. Excel vs Dataverse — Stress Test Breakdown We compare the two environments across: Row volumeConcurrencyAuditabilityAPI throughputReferential integrityLookup consistencyBehavior under updatesSecurity boundariesData lineage and governanceYou’ll learn exactly why Excel buckles under scale and why Dataverse enforces constraints that feel strict but protect the integrity of your system. Your Minimal Remediation Path (The Practical Fix) You’ll leave with a step-by-step plan to repair your Excel model and bring it into Dataverse cleanly: Model core entities (Products, Suppliers, Categories, Locations)Use surrogate GUID keysDefine alternate keys for importsNormalize data typesSplit overloaded columnsReplace text with lookupsPreprocess data in Power QueryImport parents → then childrenEnforce required relationshipsMove formulas into DataverseEnable auditing & field securityMonitor for duplicates/orphansFollow this, and your Power Apps stop corrupting data and start acting like actual systems instead of spreadsheet reenactments. Who This Episode Is For This episode is ideal for: Power Apps makersCitizen developersPower Platform adminsData analysts transitioning to DataverseTeams migrating from Excel to Power AppsOrganizations scaling low-code apps Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support. Follow us on: LInkedIn Substack

    25 min
  8. Stop Using Fragile Data: Fabric Snapshots Deliver The ONLY Version of Truth

    -3 J

    Stop Using Fragile Data: Fabric Snapshots Deliver The ONLY Version of Truth

    Most teams trust “live data” without realizing how unstable it actually is. Your analytics are constantly mutating—ETL loads rewrite history, schema shifts break reproducibility, and dashboards refresh while pipelines are mid-write. The result? Multiple “versions of truth,” no reproducibility, broken trust, and executives asking questions you can’t answer. This episode breaks down why your data is fragile, how your architecture is setting you up for failure, and why Microsoft Fabric Warehouse Snapshots are the only reliable way to guarantee stable, repeatable, audit-ready analytics at scale. You’ll learn how snapshots freeze a moment in time—transactionally consistent, read-only, and zero-copy—so pipelines can change, but your truth doesn’t. If your dashboards wobble during ETL… If finance reruns reports and gets different answers… If audits require restoring backups… Then Snapshots are your new best friend. What You Will Learn (SEO-Rich Topics & Benefits) 1. Why Your “Live Data” Is Fragile and Unreliable We break down every failure mode modern data teams face: ETL collisions causing partial data readsSchema drift breaking reproducibilityRead replicas copying volatility instead of certaintyCSV exports with no lineage or audit trailData science pipelines training on shifting baselinesMonth-end numbers changing after sign-offDashboards refreshing while tables are mid-writeThe silent cost: lost trust, wasted cycles, and decision paralysis2. The Real Root Cause: Concurrency Without Isolation Your warehouse is a construction site during loads. But your analysts are still walking through it. Snapshots solve this by separating production churn from decision-grade truth. 3. Fabric Warehouse Snapshots — What They Actually Guarantee You’ll learn the real contract: Point-in-time consistencyNo half-written rowsNo drifting results tomorrowZero-copy metadata pointer architectureImmutable state for auditing, analysis, and AI trainingSeamless client binding — same name, new timestampPurview-driven governance and RBAC enforcement4. Why Read Replicas Don’t Save You Replicas scale reads, but they mirror mutations, schema shocks, and partial loads. Snapshots freeze truth. Replicas freeze nothing. 5. Real Scenarios Where Snapshots Prevent Disaster We walk through true-to-life examples: Dashboards showing false dips during nightly loadsFinance month-end totals drifting after ETL reprocessingMachine learning models training on shifting numeric typesAudit teams asking for “as-of” data requiring full DB restoresLate facts ruining daily sales metricsAnalysts manually exporting CSVs to protect themselves6. How Fabric Snapshots Rebuild Trust Across the Business With snapshots you get: Reproducible queriesConsistent KPIsStable semantics in Power BIAudit replay in minutesMonth-end that doesn’t breakETL that runs without warning analysts “DON’T REFRESH”Data science baselines that don’t driftNo more CSV sprawlNo more cloning warehouses to freeze a state7. The Engineering Patterns That Actually Work (Templates Included) You’ll learn the three battle-tested patterns every mature data team uses: Pattern 1: Pre-ETL Snapshot for Query Stability Freeze a clean read surface before ingestion begins. Analysts read the snapshot; pipelines mutate safely behind the curtain. Pattern 2: Month-End Snapshot for Reproducible Finance Freeze the fiscal cutoff. Finance dashboards point to one stable state. No drift, no surprises, no “Why did September change?” Pattern 3: Audit Replay — Without Restores Query the exact state as-of a date, including lineage and logs. Produce evidence in minutes, not days. Detailed SEO-Optimized Section-by-Section Summary Why Your Data Is Fragile — And Why You Keep Getting Different Answers This episode explains how “freshness” creates volatility: ETL processes rewrite facts during reporting hoursAnalysts hit tables mid-writeAggregates are recalculated during dashboard refreshesSchema changes cause data driftLate-arriving facts wreck reproducibilityRead replicas simply copy chaos across serversIf you can’t run the same query tomorrow and reproduce yesterday’s answer? You don’t have analytics—you have turbulence. Fabric Snapshots as the Cure for Volatile Data Fabric Warehouse Snapshots give you: ✔ Deterministic answers ✔ Stable P&L ✔ Audit-proof history ✔ Zero-copy retention ✔ Isolation from pipeline churn ✔ Point-in-time semantics ✔ Governance built-in Snapshots freeze a database state with metadata pointers. You pay for governance and reproducibility, not duplicate storage. How Snapshots Fit Into Microsoft Fabric Architecture We explore where snapshots sit relative to: OneLakeData WarehouseLakehousePower BI semantic modelsPurview governanceETL pipelines and orchestrationDataflows and shortcutsThe secret? Snapshots act as a temporal control surface above everything else. How to Implement Snapshots (With T-SQL Patterns) You’ll learn: How to create snapshotsHow to roll them forward after validationHow to query them in Power BIHow to parameterize datasetsHow to enforce RBAC and Purview labelsHow to structure pipelines around themIncluded T-SQL patterns for: Creating snapshot baselinesRolling timestamps forwardQuerying as a snapshotListing all snapshotsDesigning retention policiesGovernance That Actually Holds Up Under Audit We cover: RBAC for snapshot controlPurview labels inherited automaticallyDLP controls for sensitive exportsSnapshot metadata catalogsRetention strategy (daily, month-end, quarter-end)Lineage linking snapshots → pipelines → transformationsAudit replay workflowCost Control and Zero-Copy Architecture Snapshots store metadata, not data. You avoid: ❌ Warehouse cloning fees ❌ Blob duplication ❌ Storage sprawl ❌ Hidden CSV caches ❌ Pipeline restarts Snapshots give you versioning with almost zero overhead. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support. Follow us on: LInkedIn Substack

    23 min

À propos

Welcome to the M365 Show — your essential podcast for everything Microsoft 365, Azure, and beyond. Join us as we explore the latest developments across Power BI, Power Platform, Microsoft Teams, Viva, Fabric, Purview, Security, and the entire Microsoft ecosystem. Each episode delivers expert insights, real-world use cases, best practices, and interviews with industry leaders to help you stay ahead in the fast-moving world of cloud, collaboration, and data innovation. Whether you're an IT professional, business leader, developer, or data enthusiast, the M365 Show brings the knowledge, trends, and strategies you need to thrive in the modern digital workplace. Tune in, level up, and make the most of everything Microsoft has to offer. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support.

Vous aimeriez peut‑être aussi