『M365.FM - Modern work, security, and productivity with Microsoft 365』のカバーアート

M365.FM - Modern work, security, and productivity with Microsoft 365

M365.FM - Modern work, security, and productivity with Microsoft 365

著者： Mirko Peters - Founder of m365.fm m365.show and m365con.net
無料で聴く

今ならプレミアムプランが3カ月 月額99円

2026年5月12日まで。4か月目以降は月額1,500円で自動更新します。

概要

 Welcome to the M365.FM — 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.FM 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. M365.FM is part of the M365-Show Network.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.Copyright Mirko Peters / m365.fm - Part of the m365.show Network - News, tips, and best practices for Microsoft 365 admins 政治・政府
エピソード
  • Stop Building Dashboards: The Proactive Notification Blueprint

    Stop Building Dashboards: The Proactive Notification Blueprint
    2026/05/03
    Your dashboard looks perfect on launch day. Clean visuals, aligned KPIs, and a sense that everything is finally “visible.” But the decay starts immediately. Because dashboards depend on one fragile assumption: someone will open them at the exact moment something matters. That rarely happens. In this episode, we challenge one of the most accepted patterns in modern BI—the idea that dashboards are the end product. Instead, we reframe analytics as an intervention system, where insight doesn’t wait to be discovered. It shows up at the right moment, in the right place, with a clear path to action. This is the shift from pull-based analytics to push-based decision systems.THE HIDDEN FAILURE OF DASHBOARD-DRIVEN THINKING Dashboards don’t fail because they’re poorly designed. They fail because they rely on human timing. People check data:When they rememberWhen they have timeWhen they already suspect a problemBut high-impact decisions fail in the gap between signal and attention. The chart existed—but nobody saw it when it mattered. That’s the break. And once you see it, dashboards stop looking like a solution. They start looking like delay infrastructure.THE RISE OF THE DATA GRAVEYARD Most dashboards don’t die dramatically. They fade. They sit in tabs. They get opened less. Eventually, they become storage instead of insight. This is what we call the data graveyard. The data might still be fresh. The visuals might still be accurate. But the system around them is broken. It depends on users stopping their work, navigating to a report, interpreting the data, and acting—fast enough for it to matter. In real organizations, that sequence collapses. People are overloaded with tools, messages, and decisions. Analytics becomes just another place to check. And once something becomes optional, it becomes ignored. WHY VISIBILITY IS NOT THE SAME AS ACTION A dashboard gives you awareness. But awareness is passive. It tells you something could be known—if someone goes looking. But it doesn’t intervene. It doesn’t interrupt. It doesn’t create urgency. That’s the gap between:Exploration (what dashboards do well)Intervention (what modern systems require)Executives don’t need more charts. They need fewer missed moments.THE SHIFT FROM PULL TO PUSH The real transformation isn’t better dashboards. It’s a different operating model. Instead of asking: “How do we visualize this data?” You ask: “What business moment deserves a response?” This is event-first thinking. You stop designing pages. You start designing moments of action:A budget crosses a thresholdAn SLA starts driftingA risk pattern emergesA process stallsThese are not reporting artifacts. They are operating events.FROM DASHBOARDS TO EVENT-DRIVEN SYSTEMS Once you adopt event thinking, everything changes. Instead of building reports, you define:Signals (what changed)Thresholds (when it matters)Owners (who is responsible)Routes (where it shows up)Actions (what happens next)This transforms analytics from a passive layer into an active decision engine.WHY MOST ALERTING STRATEGIES FAIL Many teams try to evolve by adding alerts. That usually makes things worse. Why? Because most alerts:Trigger on raw numbersIgnore contextLack clear action pathsThis creates alert fatigue. The problem isn’t just volume—it’s ambiguity. If a notification forces the recipient to investigate, interpret, and decide from scratch, it hasn’t reduced friction. It has just moved it. A good notification should arrive pre-processed:What changedWhy it matters nowWhat action is expectedWithout that, it’s noise.THE PROACTIVE NOTIFICATION BLUEPRINT To fix this, you need a structured architecture—not just alerts. A true proactive system includes six layers:SOURCE SYSTEMSWhere truth lives (ERP, CRM, service, finance, etc.)EVENT DETECTIONIdentifying meaningful change (thresholds + anomalies)AI REASONINGAdding context, summarization, and pattern understandingORCHESTRATIONCoordinating actions via Power AutomateDELIVERYSending to the right place (Teams, approvals, tasks, etc.)FEEDBACK LOOPTracking outcomes and improving the system over timeIn this model, Power BI becomes a sensor, not the final destination.WHY FEEDBACK LOOPS CHANGE EVERYTHING Without feedback, your system is blind. It keeps sending notifications without learning:Was it useful?Was it noise?Did anyone act?A closed-loop system:DetectsRoutesTracksImprovesThis is what transforms notifications into an operating layer, not just messaging.HIGH-VALUE USE CASES TO START WITH Don’t try to replace everything. Start where delay already hurts. FinanceBudget drift detection with immediate approval workflowsCash flow anomalies with routed decision pathsOperationsSLA risks with owner assignment and escalationInventory thresholds triggering replenishmentSecurity & ComplianceRisk signals routed with context and triage pathsDLP or insider risk alerts with structured responseServiceCustomer sentiment shifts triggering...
    続きを読む 一部表示
    18 分
  • Engineering Self-Healing Automation: The Telemetry-Driven Logic Layer

    Engineering Self-Healing Automation: The Telemetry-Driven Logic Layer
    2026/05/03
    Automation is evolving—and fast. What used to be simple task execution is now becoming something far more powerful: systems that can observe themselves, make decisions, and recover without human intervention. In this episode, we explore what it really means to engineer self-healing automation, and why telemetry is the missing piece that turns static workflows into adaptive systems.THE SHIFT FROM STATIC AUTOMATION TO INTELLIGENT SYSTEMS For years, automation has been built on deterministic logic: predefined triggers, fixed conditions, and predictable outcomes. But modern environments—especially cloud, SaaS, and distributed systems—are anything but predictable. Conditions change constantly, signals are noisy, and dependencies are complex. This is where traditional automation starts to break down. Instead of rigid workflows, we now need systems that can interpret signals dynamically. Systems that don’t just execute, but decide. This shift marks the transition from automation as a tool… to automation as a system.WHY TRADITIONAL AUTOMATION FAILS AT SCALE Most automation fails not because the idea is wrong—but because the design is incomplete. Static workflows assume:Stable environmentsPredictable inputsLinear cause-and-effect relationshipsIn reality, you’re dealing with:Distributed servicesRapid configuration changesUncertain and evolving conditionsThe result? Broken flows, alert fatigue, and constant manual intervention. Automation becomes something you maintain, not something that maintains itself.ENTER THE TELEMETRY-DRIVEN LOGIC LAYERTelemetry is everywhere—logs, metrics, traces, events. But collecting data isn’t enough. The real value comes from interpreting that data and turning it into decisions. That’s where the Telemetry-Driven Logic Layer comes in. This layer sits between raw signals and automated actions. It acts as the brain of your automation system:It ingests telemetry from multiple sourcesIt applies context and correlationIt evaluates conditions dynamicallyIt determines the best course of actionInstead of hardcoding every scenario, you create a system that can adapt to new ones.FROM “IF THIS THEN THAT” TO “OBSERVE, DECIDE, ACT”Traditional automation follows a simple model:IF condition → THEN action Self-healing automation follows a more advanced loop:OBSERVE → ANALYZE → DECIDE → ACT → LEARN This feedback loop is what enables systems to evolve over time. They don’t just respond—they improve.BUILDING SELF-HEALING SYSTEMS IN PRACTICE So how do you actually design for self-healing? It starts with three foundational components:OBSERVABILITY (THE INPUT LAYER)Collect meaningful telemetry across systems—metrics, logs, user signals, and performance data. The goal is not more data, but better signals.DECISION ENGINE (THE LOGIC LAYER)This is where intelligence lives. You define rules, thresholds, and models that interpret telemetry and determine actions.AUTOMATED EXECUTION (THE ACTION LAYER)Actions are triggered based on decisions—remediation, scaling, policy enforcement, or workflow adjustments.When these components are connected through a feedback loop, you get a system that continuously refines itself.REAL-WORLD USE CASES OF SELF-HEALING AUTOMATION This isn’t just theory—it’s already happening. Imagine:A system detects abnormal API latency and automatically reroutes trafficA security anomaly triggers adaptive access policies in real timeA failed workflow self-corrects based on historical success patternsA resource spike initiates scaling actions before users are impactedIn platforms like Microsoft 365 and cloud-native environments, these patterns are becoming essential—not optional.THE ROLE OF FEEDBACK LOOPS IN MODERN AUTOMATION The real breakthrough isn’t automation—it’s feedback. Without feedback, automation is blind.With feedback, it becomes intelligent. Telemetry provides that feedback by:Validating whether actions were successfulIdentifying unintended consequencesContinuously refining decision logicThis is what transforms automation into a living system.DESIGN PATTERNS FOR TELEMETRY-DRIVEN AUTOMATION To implement this effectively, consider these patterns:EVENT-DRIVEN ARCHITECTUREReact to real-time signals instead of scheduled triggersCORRELATION OVER ISOLATIONCombine multiple signals to reduce false positivesGRADUAL AUTOMATION MATURITYStart with assisted automation, then move to full autonomyHUMAN-IN-THE-LOOP DESIGNKeep humans involved where decisions carry riskCOMMON PITFALLS TO AVOID Even advanced automation can fail if poorly designed. Watch out for:Over-automation without contextPoor signal quality leading to bad decisionsLack of visibility into automated actionsNo rollback or safety mechanismsSelf-healing doesn’t mean uncontrolled—it means intelligently controlled.THE FUTURE: AUTONOMOUS OPERATIONS We’re moving toward a world where systems manage themselves. Not entirely without humans—but with far less manual intervention. ...
    続きを読む 一部表示
    20 分
  • Legacy Power Apps Portals: The Silent Budget Killer

    Legacy Power Apps Portals: The Silent Budget Killer
    2026/05/02
    The assumption that your legacy portal is stable because it’s “quiet” is one of the most expensive mistakes hiding in your IT budget. These systems were built for structure, navigation, and hierarchy. But modern work doesn’t start with menus—it starts with context, data, and real-time decisions. What looks stable on the surface is often a governance black hole underneath, where logic hides outside the reach of your security team. The upcoming changes across platforms like Microsoft Power Platform are not just incremental updates. They act as a structural audit. They expose shortcuts, hidden dependencies, and architectural decisions that no longer hold up. Right now, your portal feels fine because the lights are on. But stability without visibility is not stability—it’s risk delayed.🕳️ THE GOVERNANCE BLACK HOLE Most organizations believe their rules live safely inside Microsoft Dataverse. On paper, that assumption makes sense. In reality, legacy portals introduced a hidden layer where logic lives outside standard auditing. This “shadow logic” often sits inside Liquid templates—unversioned, hard to track, and invisible to modern governance tools. The danger isn’t just technical debt. It’s the illusion of control. When your security team runs an audit, they expect one source of truth. But legacy portals operate in parallel, where rules can be overridden, bypassed, or simply missed. This creates a gap between what you think is enforced and what actually happens. The risk becomes obvious when you need full transparency:Business rules exist outside audit logsData access depends on hidden template logicSecurity reviews require manual investigationYou can’t govern what you can’t see. And right now, your portal is hiding more than you realize.⚠️ THE JAVASCRIPT INJECTION TRAP For years, JavaScript injections were the quick fix. Need validation? Add a script. Need UI logic? Inject code. It worked—until scale and security entered the conversation. Client-side logic is not enforcement. It’s a suggestion. Everything written in JavaScript is visible, editable, and bypassable in the browser. That means your validation, your business rules, even your pricing logic can be manipulated with a simple developer console. What once felt efficient has now become a structural weakness. The real cost shows up over time. Every script adds complexity, every workaround adds fragility, and every update risks breaking something unexpected. Your developers are no longer building—they are maintaining patches. This creates a pattern:Logic is exposed to the browser instead of secured on the serverMaintenance effort grows faster than actual business valuePerformance and scalability degrade under accumulated fixesModern architectures shift this logic back where it belongs—into secure, server-side processes. Not because it’s cleaner, but because it’s the only way to scale safely.🔐 THE 2026 SECURITY UNIFICATION One of the biggest hidden risks in legacy portals is the split identity model. External users exist as contacts. Internal users exist as system users. Security is divided across web roles and Dataverse roles, creating a fragmented view of access. The 2026 updates begin to unify this model. Users will still exist as contacts, but they will also align with Dataverse identities. This brings enforcement, auditing, and visibility into a single system. It reduces guesswork and eliminates the need to stitch together access logic manually. But this shift also exposes old assumptions. If your architecture relied on that separation, you will feel the impact—not because the system breaks, but because the hidden dependencies become visible. This is where many organizations realize they weren’t running a secure model—they were running a fragmented one. 🧑‍💻 TECHNICAL DEBT AS A CAREER RISKLegacy systems don’t just cost money. They cost momentum. The talent required to maintain outdated portal architectures is becoming rare and expensive. At the same time, modern developers are focused on APIs, automation, and scalable platforms—not debugging five-year-old templates. This creates a growing disconnect between your technology stack and the talent market. When your system depends on shrinking expertise, you introduce a new kind of risk. Not technical failure—but knowledge loss. The longer you stay on a legacy model, the more you invest in skills that are disappearing, while missing out on capabilities that define the future. This isn’t just an operational issue. It’s a strategic one. 🤖 THE AI READINESS WALL Every organization is talking about AI. Copilots, agents, automation. But AI doesn’t work with hidden logic and fragmented systems. AI needs structured, accessible, and machine-readable rules. Legacy portals were built for human navigation. They rely on UI-driven logic, client-side scripts, and scattered configurations. That makes them fundamentally incompatible with ...
    続きを読む 一部表示
    16 分
まだレビューはありません