Support the Podcast
Contacts
Info
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,...
show more
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.
show less
M365.FM - Modern work, security, and productivity with Microsoft 365
M365.FM - Modern work, security, and productivity with Microsoft 365
Mirko Peters (M365 Consultant)Support the Podcast
Episodes & Posts
Episodes
Posts
Transcribed
20 APR 2026 · Most teams don’t actually have an automation problem — they have a model problem. Organizations are still building workflows as if business processes move in clean, predictable steps. But modern operations don’t work like that anymore. Today, decisions depend on a constant stream of signals coming from apps, APIs, identities, data platforms, and people — all happening at once. The traditional workflow model simply can’t keep up with this level of complexity and speed. What follows is a hidden slowdown. One flow calls another, which calls an API, which triggers something else entirely. On the surface, it looks automated. Underneath, delays stack up across every handoff. The more you scale, the slower the system actually becomes. In this episode, we break down:
- Why workflow-first thinking creates automation debt
- How event-driven orchestration reduces decision latency
- Where Power Platform APIs change the architecture
⚠️ THE OLD MODEL IS BREAKING: WORKFLOWS OPTIMIZE STEPS, NOT TIME
The traditional workflow model is built around sequences. Something triggers, a chain of steps runs, and eventually, the process completes. This worked in slower, predictable environments where the goal was simply to ensure each step executed correctly. But that’s not the reality anymore. Modern business demands immediate reaction:
- Security alerts can’t wait
- Transactions trigger downstream dependencies instantly
- Decisions must happen in real time
The real issue isn’t whether a workflow finishes — it’s how long it takes to respond. What goes wrong:
- Logic gets layered into complex branching
- Multiple teams own different parts of the flow
- Delays accumulate across connectors, retries, and approvals
Individually, these delays seem small. Together, they create serious operational drag.
🧠 THE REAL PROBLEM: DECISION LATENCY
Instead of focusing on workflow completion, we need to focus on decision latency — the time between an event happening and the correct action starting. Hidden delays include:
- API response lag
- Queue wait times
- Connector throttling
- Human approval bottlenecks
Average performance hides these issues. The real cost sits in the long tail (p95 latency), where delays compound and impact the business most. 🔗 WHY WORKFLOWS CREATE AUTOMATION DEBT As workflows grow, they turn into fragile chains of dependencies.
- One flow triggers another
- Ownership becomes unclear
- Logic gets buried in nested conditions
- Small changes create unpredictable side effects
What looks like centralized control is often just hidden complexity. The outcome:
- Slower change cycles
- Increased risk of failure
- Poor visibility into real system behavior
🚀 THE NEW MODEL: EVENTS AS THE BUSINESS API LAYER
The shift is simple but powerful:
👉 Stop asking: “What happens next?”
👉 Start asking: “What just happened?” An event represents a meaningful business moment:
- IncidentDetected
- UserProvisioned
- InvoiceSubmitted
Instead of driving a sequence, events broadcast a fact that multiple systems can react to simultaneously. Key advantages:
- Parallel processing instead of sequential delay
- Clear ownership per reaction
- Smaller, more maintainable logic units
🔧 HOW POWER PLATFORM CHANGES THE GAME
Modern Power Platform capabilities enable this shift from workflows to orchestration. Key architectural changes:
- Dataverse business events → represent confirmed business facts
- Custom APIs → expose reusable logic at the edge
- Native connectors → reduce overhead and latency
- Event-driven patterns → enable cross-system orchestration
Why this matters:
- Fewer API calls
- Lower throttling risk
- Faster response times
- Cleaner system boundaries
🏗️ WHAT TO ENDORSE (NEW BEST PRACTICES)
✅ BUILD FOR SCALE AND CLARITY
- Use managed identities instead of user-owned connections
- Define and maintain an event catalog
- Design small, focused handlers (one event → one reaction)
- Track end-to-end event latency, not just flow runs
🚫 WHAT TO RETIRE (OLD PATTERNS)
❌ AVOID THESE ANTI-PATTERNS
- Polling-based integrations
- Long-running “mega flows”
- Centralized orchestration logic
- Hidden business rules inside workflows
If your logic lives inside one massive flow, it doesn’t scale — and it hides risk.1
🧭 HOW TO START WITHOUT BREAKING EVERYTHING
You don’t need a full rebuild — start small and strategic.
STEP-BY-STEP:
- Identify one process where latency matters
- Map the real workflow (including hidden delays)
- Define key business events
- Replace one large flow with:
- Event publication
- Small, focused reactions
KEY RULE:
- No new cross-system logic inside a single flow
Use a strangler pattern:
- Introduce events gradually
- Replace parts of the system over time
- Retire legacy flows once stable
🧠 FINAL TAKEAWAY
Business doesn’t move in steps — it moves in moments. Workflow-based automation is failing because it tries to control sequences instead of enabling fast reactions. The shift:
- From workflows → to events
- From sequences → to orchestration
- From control → to clarity and speed Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.
Transcribed
19 APR 2026 · Your organization doesn’t have a focus problem — it has a notification architecture problem. Most teams blame poor focus on habits, discipline, or time management. But the reality is different:
your Microsoft 365 environment is designed to interrupt people constantly. Teams pings. Outlook banners. Red badges. Mobile alerts.
All of it pulls attention sideways — and then we wonder why deep work never happens. In this episode, we break down:
- Why M365 defaults push teams into reaction mode
- How constant notifications slow decisions and stretch work
- What leaders must change first to restore focus and clarity
⚠️ THE MODEL IS BROKEN: PRODUCTIVITY = RESPONSIVENESS
Most organizations still reward:
- Fast replies
- Constant visibility
- Active chat participation
But responsiveness ≠ progress.
- Someone can reply to 20 messages and move nothing forward
- Another can go silent for 90 minutes and solve the real problem
Yet the system rewards the first. The Result:
- Decision-making slows down
- Work gets fragmented
- Meetings increase
More notifications don’t speed things up — they delay decisions.
🧠 THE HIDDEN COST: FRAGMENTED ATTENTION
Deep work requires:
- Continuity
- Context
- Time to think
But constant interruptions:
- Break mental flow
- Force “reload time” when returning to tasks
- Stretch simple work across hours
What Happens Next:
- Tasks take longer than necessary
- Teams lose trust in async communication
- Meetings replace clarity
⚡ THE NEURAL TAX OF THE PING
Notifications don’t need clicks to cause damage.
- Even a quick glance shifts your focus
- It can take ~23 minutes to fully refocus
- A single notification can disrupt thinking for ~7 seconds
The Real Impact:
- Cognitive drag builds up all day
- Mental energy drains faster
- Focus becomes fragile
🔴 WHY BADGES AND ALERTS ARE SO ADDICTIVE
Unread notifications create open loops in your brain.
- They signal unfinished work
- They trigger urgency (even when fake)
- They pull attention away from deep tasks
This leads to:
- Preference for quick replies over meaningful work
- Constant checking behavior
- Illusion of productivity
⚙️ THE DEFAULT SETTINGS TRAP IN M365
Most organizations never question the defaults. Teams:
- Constant activity feeds
- Overuse of @mentions
- Presence indicators driving pressure
Outlook:
- Desktop pop-ups interrupt constantly
- Inbox treated like real-time chat
Viva:
- Focus time exists but isn’t enforced
- Meetings override deep work
SharePoint:
- Alert sprawl creates noise
- Important updates get buried
Mobile:
- Work follows users everywhere
- No real boundary between work and personal time
💸 THE BUSINESS COST LEADERS ACTUALLY FEEL
This isn’t just a productivity issue — it’s an operational problem. Key Impacts:
- Slower decision velocity
- Longer cycle times
- Increased meeting hours
- Reduced execution quality
Hidden Cost:
- Teams look busy but deliver slower
- Leaders lose strategic thinking capacity
- Signal quality collapses
Attention is your organization’s operating capacity.
📊 REAL-WORLD CASE: WHAT CHANGED
A global services firm (~8,000 users) faced:
- 120–180 notifications per user per day
- ~6.5 hours of meetings daily
- Almost zero focus time
What They Changed:
- Reduced Teams noise (mentions only baseline)
- Disabled Outlook pop-ups
- Introduced focus blocks (Viva)
- Set mobile quiet hours
- Removed expectation of instant replies
Results (within 90 days):
- 📉 45% fewer notifications
- 📉 18% fewer meeting hours
- ⏱ +2.1 hours of focus time per week per user
- 🚀 Improved project delivery speed Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.
Transcribed
19 APR 2026 · Microsoft 365 Copilot is not a rollout decision. It is a governance decision with a very short runway. Most leadership teams approach it as enablement, but Copilot operates on the environment exactly as it exists today—not as you intend it to be tomorrow. In multi-tenant organizations, this creates a structural problem. AI operates within tenant boundaries, while risk moves across them. What looks like one unified Microsoft 365 environment is, in reality, a collection of independent systems with different controls, different maturity levels, and different exposure. In this episode, Mirko Peters breaks down why the illusion of a global AI control plane is dangerous, how governance drift accelerates with Copilot, and what model actually works when you need to scale safely across multiple tenants.
🧠 CORE IDEA
Most organizations believe they are enabling AI across one environment. They are not. They are activating AI across multiple independent governance systems that only appear connected.
- AI works within tenant boundaries
- Risk moves across tenant boundaries
- Governance does not automatically follow identity
👉 Copilot does not unify your environment
👉 It exposes the differences inside it
⚠️ THE MULTI-TENANT COPILOT TRAP
The trap starts with familiarity. Everything looks connected—same vendor, same branding, shared identity. This creates the illusion of central control. But underneath:
- There is no single global AI admin center
- Governance is fragmented across Purview, Entra, and admin portals
- Each tenant enforces its own version of policy and data control
What you actually have:
- Multiple AI environments
- Multiple policy realities
- Multiple levels of risk
👉 You don’t have one enterprise AI system
👉 You have sovereign AI islands inside one company
🧩 WHY THIS BREAKS GOVERNANCE
When tenants drift, governance stops being comparable. Each tenant reports “we are governed”—but means something different:
- Audit enabled vs. audit usable
- Labels created vs. labels applied
- Identity connected vs. control aligned
- Copilot deployed vs. Copilot governed
This creates structural misreporting:
- Leadership sees one program
- Reality is multiple operating conditions
- Evidence becomes inconsistent
👉 Reporting doesn’t lie intentionally
👉 It lies structurally
🔄 WHY MANUAL GOVERNANCE FAILS AT SCALE
The natural response is to govern tenant by tenant. This feels disciplined—but it is not scalable. Manual governance creates variation over time:
- Each team interprets standards differently
- Each tenant moves at a different speed
- Local exceptions accumulate quietly
What looks like control is actually repetition. And repetition produces drift:
- Policy drift
- Access drift
- Rollout drift
👉 Human effort creates activity
👉 Not consistency
⚡ WHY COPILOT ACCELERATES THE PROBLEM
Copilot does not wait for governance maturity. It operates on what already exists:
- Existing permissions
- Existing oversharing
- Existing labeling gaps
- Existing audit limitations
The moment users start prompting:
- Hidden exposure becomes visible
- Overshared content becomes accessible
- Inconsistent controls become operational
👉 AI does not create risk
👉 It removes the friction that used to hide it
🔐 WHY IDENTITY DOES NOT SOLVE GOVERNANCE
Many organizations assume identity is the solution. If users can move across tenants, governance should follow. It does not.
- Copilot operates within a single tenant context
- Permissions are enforced per tenant
- Data grounding is tenant-specific
What this means:
- Identity can traverse
- Governance cannot
Even multitenant capabilities today show clear limitations:
- No full cross-tenant policy enforcement
- Limited authentication scenarios
- Gaps in connectors and analytics
- Incomplete audit visibility
👉 Cross-tenant identity is not cross-tenant intelligence
🏗️ THE MODEL THAT ACTUALLY WORKS
To scale safely, governance must match reality. That means adopting a hub-and-spoke model.
THE HUB:
- Defines global policy standards
- Owns audit baselines and label taxonomy
- Sets rollout criteria and enforcement rules
- Measures governance across all tenants
THE SPOKES:
- Execute governance locally within each tenant
- Apply standards to real environments
- Run remediation and validation
- Handle exceptions through a controlled process
Key rule:
- No Copilot rollout without validated audit logging
- No rollout without oversharing review
- No rollout without baseline label coverage
👉 Global does not mean one portal
👉 It means one governance system
📊 WHAT LEADERS MUST MEASURE
Governance only works if it produces shared, comparable metrics. Key metrics:
- Oversharing reduction
- Observability coverage across tenants
- Time-to-policy enforcement
- Label coverage consistency
- Access drift rate
What matters:
- Exposure must decrease before AI expands
- Logging must exist before scale
- Policy must apply everywhere—not eventually
👉 If you cannot measure it across tenants Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.
Transcribed
18 APR 2026 · Most organizations think building an app is about screens, features, or tools. It’s not. Because apps don’t create value on their own—they change how work enters the business. And if the entry point is weak, everything behind it becomes slower, messier, and harder to trust. In this episode, we break down why your first Power App matters far more than it looks—and why the real shift isn’t “having an app,” but turning intent into structured, visible, and actionable work.
🚀 What You Will Learn
- Why data alone doesn’t change business behavior
- The critical difference between stored intent vs executed process
- Why most first apps fail before anyone even opens them
- How to define a business problem in operating terms (not features)
- The real difference between Canvas and model-driven apps
- Why your first app is a business interface—not a demo
- How to reduce cycle time by fixing the entry point
- The hidden risks of default environments and licensing decisions
- How to handle real-world complexity without overbuilding
- Why the best first app should feel boring (and that’s a good thing)
🧠 Core Insight
You didn’t build an app.
You redesigned how work enters the system.
- A request in email → creates ambiguity
- A request in Dataverse → creates structure
- A request with status → creates visibility
Behavior doesn’t change when data exists.
It changes when interaction becomes easier than the workaround.
❌ Why First Apps Fail
- Teams start with screens instead of process intent
- Old workflows get copied into new interfaces
- Too many features get added before trust exists
- Complexity gets pushed onto users instead of the system
- Licensing and environment decisions are made accidentally
- The app looks modern—but behavior stays the same
⚠️ Failure Patterns 1. Digitizing the mess
- Email → becomes a form
- Spreadsheet → becomes fields
- Confusion → becomes UI
👉 Same problem, better visuals 2. Overbuilding too early
- Edge cases dominate design
- Main path becomes unclear
- First release becomes fragile
👉 Complexity replaces clarity 3. Confusing storage with execution
- Data exists, but process doesn’t move
- Tables are created, but behavior stays unchanged
👉 “We have the data” ≠ “The system works”
🧩 Core Model Every first app must align three things:
- Event → How work enters the system
- Decision → What happens next
- Status → What everyone can see
If these are unclear, the app becomes decoration—not operation.
🔑 Key Takeaways
- Your first app is a front door, not a full system
- Adoption comes from reducing friction, not adding features
- Canvas = interaction-first (front door)
- Model-driven = structure-first (operations workspace)
- Dataverse is not storage—it’s business structure
- Simplicity creates trust → trust creates usage
- Fixing entry improves everything downstream
🏗️ The Architectural Shift Move away from:
- Feature-first thinking
- UI-driven design
- “Let’s include everything” releases
- Email + memory-based processes
Move toward:
- Clear entry points
- Structured records in Dataverse
- Shared status models
- Separation of interaction vs orchestration
⚙️ Practical Shifts
- Make the right path easier than the workaround
- Capture only what the next decision needs
- Keep the first app small and focused
- Store complexity in the data model—not the UI
- Avoid default environment for real solutions
- Avoid unnecessary premium connectors early
⚡ The 30-Day Move Pick one process that still runs through:
- Email
- Teams messages
- Memory
Then:
- Define:
- Event
- Decision
- Status
- Build:
- One clean entry (Canvas app)
- One structured record (Dataverse)
- Measure:
- Time to submit
- Time to respond
- Number of follow-ups
If the process becomes faster and clearer, you’re on the right path.
🎯 Who This Episode Is For
- IT leaders starting with Power Platform
- Architects designing first-use cases
- Makers building their first real app
- HR / Operations teams stuck in email workflows
- Anyone whose “process exists”—but doesn’t actually work
💡 Final Thought
Your first app is not about Power Apps. It’s about changing how work begins. Because once the entry point becomes structured, visible, and trusted— everything behind it starts to move. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.
Transcribed
17 APR 2026 · In this episode of m365.fm, Mirko Peters takes a step back from the usual Power Apps conversation and focuses on what actually determines success or failure long before any app is built: the data foundation. Most teams start with screens, automation, or user experience. But when apps begin to break down after a few months, the root cause is almost never the interface. It is the structure underneath. This episode reframes Dataverse not as a storage solution, but as an operating model that defines how your business behaves at scale. If you are working with Power Apps, Power Automate, or Copilot, this conversation will challenge how you think about architecture, cost, and long-term sustainability inside Microsoft 365.
💡 Why This Episode Matters
What looks fast and efficient at the beginning often becomes fragile under pressure. Excel files multiply, SharePoint lists drift, and suddenly no one fully trusts the data anymore. Teams start compensating with manual work, duplicate records, and endless coordination. This episode explains why that pattern is not a user problem or even a tooling problem. It is a system design problem. And more importantly, it shows how Dataverse changes system behavior by enforcing structure, relationships, ownership, and consistency across your processes.
🧠 The Core Insight
Most organizations compare tools based on cost or familiarity. They ask whether SharePoint or Excel is “good enough” and treat Dataverse as a premium upgrade. But that comparison misses the real question. You are not choosing where your data lives.
You are choosing how your business behaves under load. When your foundation is weak, people compensate. They create copies, side systems, and manual checks. Over time, the system starts negotiating with itself before any real work can happen. Dataverse changes that dynamic by making structure non-optional. Relationships are enforced, ownership is explicit, and data stops drifting across disconnected places. The result is not just cleaner data—it is faster processes, higher trust, and systems that can actually scale.
⚙️ What You’ll Learn
Throughout the episode, Mirko walks through the hidden cost patterns most teams miss and why “cheap” solutions often become expensive over time. He explains how:
- Coordination cost silently replaces licensing cost when structure is weak
- Flat data models lead to duplication, inconsistency, and reporting chaos
- Delegation limits in SharePoint create incomplete truths inside apps
- Data quality issues are usually system outcomes, not user mistakes
- Cycle time drops dramatically when systems stop requiring interpretation
You will also understand why governance, ownership, and access design are not optional layers, but core parts of your architecture from day one.
🏗️ Dataverse as an Operating Model
One of the most important shifts in this episode is understanding that Dataverse is not about storing records differently. It is about enforcing behavior. Instead of relying on team discipline, the platform itself ensures that data is structured, relationships are preserved, and rules are applied consistently. This reduces ambiguity across the entire system—from apps to automation to reporting and even AI. That is why Dataverse becomes critical the moment your processes move beyond simple tracking into shared, cross-team operations.
🤖 Why This Matters for AI and Copilot
A major theme in this episode is how AI exposes weak foundations. Many organizations expect Copilot and agents to deliver insights, but the underlying data is fragmented, duplicated, or inconsistent. The result is AI that sounds confident but lacks real grounding. Dataverse provides the structure AI needs to be useful. Because AI does not fail due to lack of intelligence.
It fails due to lack of structure.
👥 Who This Episode Is For This episode is especially relevant if you are:
- Designing Power Apps or Power Platform solutions
- Responsible for Microsoft 365 architecture or governance
- Leading digital transformation or automation initiatives
- Struggling with data consistency, reporting, or process scalability
- Exploring AI and Copilot scenarios on top of business data
If your organization is growing and your current systems feel increasingly fragile, this episode will give you a new lens to understand why.
🚀 Final Thought
Every app you build already depends on a foundation. The real question is whether that foundation can hold once the business starts relying on it. Dataverse is not about making your apps better on day one.
It is about preventing them from breaking on day one hundred. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.
Transcribed
16 APR 2026 · In this episode, we explore why most Power Platform solutions fail long before anything is built. The issue is rarely the tool itself, but the starting point: teams define a solution before they truly understand the problem. When you begin with “let’s build an app,” you immediately narrow the conversation and miss the structural reality behind the process. Power Platform is not a single product but a system of roles, and confusion starts when these roles are treated as interchangeable. Each tool operates on a different layer of the business, and only when those layers are clearly separated does the platform start to make sense.
- Power Apps → interaction layer
- Power Automate → execution layer
- Power BI → visibility layer
- Power Pages → external access
- Copilot → assistant layer
When teams collapse these into one idea of “building something,” they often create solutions that look good in demos but fail in operations.
🏭 From “we need an app” to real system thinking
A simple example like a vacation request process quickly reveals the deeper issue. What looks like a need for an app is usually a combination of unclear input, delayed approvals, manual handoffs, and missing visibility. The problem is not the interface—it is the system relying on people to connect disconnected parts. Instead of reacting to the most visible pain point, the focus needs to shift toward identifying where the system actually breaks:
- inconsistent data entering the process
- unclear ownership and approval logic
- manual coordination between teams
- lack of real-time insight
Each of these requires a different architectural response, which is why tool choice must follow diagnosis—not the other way around.
⚡ The 3 forces that shape every decision Before selecting any tool, three forces determine whether a solution will hold up:
- Data gravity → where the data lives and whether it can be trusted
- Process criticality → how often it runs and what breaks when it fails
- Identity & governance → who has access and who owns the system
If these are unclear, every layer built on top becomes fragile. If they are clear, tool selection becomes almost obvious.
🔄 Choosing the right starting point
The most important shift is understanding that you don’t start with a tool—you start with the dominant constraint in the system.
- If delays are the issue → focus on automation first
- If data is inconsistent → fix the structure first
- If visibility is missing → introduce reporting early
From there, a stable sequence emerges:
- define the data
- design the process
- build the interface
- add visibility
- introduce AI if it adds value
Reversing this order is one of the most common reasons solutions fail.
⚠️ Why “quick builds” create long-term problems
Many teams fall into the same pattern: a SharePoint list is created, a Power App is added, flows are layered on top, and Excel remains in the background. While this feels fast, it usually leads to duplicated data, broken trust, and unreliable reporting. This is not a limitation of the platform—it is the result of skipping structural decisions early on. The alternative is a governed approach, where data, ownership, and process logic are defined upfront. While this feels slower at first, it reduces rework, lowers operational cost, and increases trust across the system.
🤖 AI, governance, and the future of the platform
AI and Copilot introduce a new layer of interaction, but they do not replace architecture. Instead, they amplify whatever foundation already exists. A well-structured system becomes faster and easier to use, while a weak one spreads inconsistency at scale. As automation increases, governance becomes critical. Decisions happen faster, access becomes dynamic, and workflows run continuously. Without control, systems don’t just scale efficiency—they scale risk.
🎯 Key takeaways
- most failures come from starting with a solution instead of the problem
- the platform works as a system of layers, not a single tool
- data, process, and governance must be stable first
- tool choice is really about sequence, not preference
- AI accelerates systems but does not fix them
💬 Final thought
The platform doesn’t fail in the way most people think—it usually does exactly what it was asked to do. When outcomes fall short, the issue is almost always the starting point. If you define the problem clearly and stabilize the right layer first, the tools stop competing and start working together.
👤 About the host
Mirko Peters is a Microsoft 365 architect and the host of m365.fm. He works with organizations of all sizes to design systems that replace manual coordination with structured, automated workflows. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.
Transcribed
15 APR 2026 · In this episode, you’ll learn why your biggest operational risks are not visible in your tools—but hidden inside your process architecture. You’ll understand how Excel-based shadow systems silently shape your business, why they create instability at scale, and how governance—not tools—is the key to fixing them.
🚀 What You’ll Learn
- why Excel shadow-systems are an architectural problem, not a tool problem
- how hidden coordination destroys performance, trust, and scalability
- why process architecture—not effort—determines business outcomes
This episode is ideal for architects, consultants, IT leaders, and anyone working with Microsoft 365, Power Platform, and modern cloud governance.
⚠️ THE EXCEL SHADOW-SYSTEM PROBLEM
Most organizations believe their processes are structured and controlled. They are not. Instead, they operate on a hidden layer of:
- spreadsheets acting as databases
- email acting as workflow engines
- people acting as integration layers
This creates what we call a shadow-system—an unofficial architecture that runs the business without governance, visibility, or control.
🏢 THE “NORMAL” COMPANY ILLUSION
From the outside, companies like Contoso look stable:
- Microsoft 365 is deployed
- Teams and Outlook are heavily used
- reports are delivered on time
But underneath, work flows through:
- Excel files like Final_v7_Approved_UseThisOne.xlsx
- email threads instead of workflows
- personal memory instead of system logic
The business appears functional—but it runs on invisible coordination.
⏱️ SIGNAL #1: APPROVAL CYCLE TIME DRIFT
A process designed to take 1–2 days often takes 5–12 days in reality. Why? Because time is lost in:
- inbox waiting
- unclear ownership
- attachment confusion
- manual follow-ups
The issue is not slow people.
👉 It’s slow architecture.
🔁 SIGNAL #2: REWORK AS A SYSTEM OUTCOME
Rework is not a mistake. It’s a design failure. Typical symptoms:
- duplicate data entry
- version conflicts
- repeated approvals
- constant reconciliation
Up to 15–30% of work is often pure rework. That’s not inefficiency—it’s structural waste.
📉 SIGNAL #3: DATA INCONSISTENCY → TRUST FAILURE
Different teams produce different answers to the same question. This leads to:
- meetings becoming reconciliation sessions
- decisions being delayed
- dashboards losing credibility
When trust in data drops, the business stops running on systems… …and starts running on people.
👤 THE HIDDEN RISK: KEY-PERSON DEPENDENCY
“Only Sarah understands this spreadsheet.” That sentence defines a fragile system. Key-person dependency means:
- knowledge is concentrated
- processes are undocumented
- resilience is low
👉 The company is not running on process. It is running on memory.
⚡ WHY SHADOW SYSTEMS KEEP COMING BACK
Excel is not the problem. It is the fastest available solution to friction. Teams use it because:
- it’s immediate
- it requires no approval
- it solves problems instantly
This creates two speeds:
- formal delivery (slow)
- survival delivery (fast)
Excel lives in the gap between them.
🧠 THE REAL ISSUE: ARCHITECTURE, NOT TOOLS
The shadow-system is not chaos. It is a functional architecture:
- files = database
- email = workflow engine
- people = middleware
It works—but it is:
- ungoverned
- invisible
- fragile
🔄 FROM SHADOW-SYSTEM TO GOVERNED FLOW
When organizations move to a governed model (e.g., Power Platform), everything changes structurally:
BEFORE (Excel System)
- hidden routing
- manual coordination
- unclear state
- fragmented data
AFTER (Governed Architecture)
- structured intake
- automated routing
- visible state
- shared data model
📊 REAL IMPACT (CONTOSO EXAMPLE)
After redesigning just one process:
- cycle time: 9 days → 2.5 days
- rework: 22% → <5%
- visibility: zero → real-time
This is not automation.
👉 This is architectural transformation.
🤖 WHY AUTOMATION ALONE IS NOT ENOUGH
Automation without governance:
- speeds up bad processes
- hides broken logic faster
- increases risk
The real shift is:
👉 from manual vs automated
👉 to ambiguous vs governed
🧭 GOVERNANCE IS THE PERFORMANCE SYSTEM
High-performance environments require:
- enforced standards
- clear ownership
- observable flow
- continuous control
Governance is not restriction.
👉 It is what makes scale possible.
🧱 THE MODERN OPERATING MODEL
To fix shadow-systems, organizations must adopt: 1. Governance-led design Defines rules, boundaries, and structure 2. Business-owned processes Domain teams own logic and outcomes 3. Platform-enabled delivery Power Platform enables scalable execution
🤖 AI CHANGES EVERYTHING (AND NOTHING)
AI accelerates creation—but not design quality. Without governance:
- bad processes scale faster
- risks multiply instantly
- shadow-systems become smarter
👉 AI does not fix architecture.
👉 It amplifies it. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.
Transcribed
14 APR 2026 · Most organizations try to fix governance with more policy, more approvals, and more oversight. It doesn’t work. Because governance that sits outside the workflow becomes friction — and friction gets bypassed. In this episode, we break down why governance fails even when everything looks correct on paper—and why scalable organizations don’t enforce control through people, but embed it into the architecture so the right behavior happens automatically.
🚀 What You Will Learn
- Why governance on paper doesn’t translate into real control
- Why AI (like Copilot) exposes problems instead of creating them
- The difference between intent, mechanics, and behavior
- Why slow governance gets bypassed under pressure
- How feature-based governance creates fragmentation
- What control surfaces are and why they matter
- Why more policy often makes systems more fragile
- How to design governance that works at business speed
🧠 Core Insight
Governance is not what you define.
It’s what your system produces.
- Control that depends on people → creates delay and inconsistency
- Control embedded in the workflow → creates scale
❌ Why Governance Fails
- Policies define intent, but don’t enforce behavior
- Governance sits outside the flow of work
- AI reveals existing overexposure at scale
- Slow processes create pressure to bypass
- Workarounds become the real operating model
⚠️ Failure Patterns 1. AI doesn’t create chaos — it reveals it
- Existing permissions become visible
- Hidden exposure turns into active risk
- The system behaves correctly — the architecture doesn’t
2. Governance that slows work gets bypassed
- Approval-heavy models introduce delay
- Teams route around friction
- Unofficial paths become standard
3. Governance built as documentation, not system
- Policies exist, mechanics don’t
- Users interact with tools—not policy decks
- The environment defines behavior
🧩 Core Model Governance breaks when these drift apart:
- Intent → What the organization defines (policy, risk posture)
- Mechanics → What the system enforces (controls, defaults)
- Behavior → What people actually do under pressure
📉 Why More Policy Makes It Worse
- Adds complexity without changing behavior
- Increases workflow friction
- Pushes work into unmanaged channels
- Reduces visibility
- Creates false confidence at leadership level
🔑 Key Takeaways
- Governance is a system problem, not a people problem
- AI amplifies existing weaknesses
- Control outside the workflow creates bypass
- Feature management ≠ governance
- Architecture defines behavior—not documentation
- Scale comes from reducing decision pressure
🏗️ The Architectural Shift Move away from:
- Feature toggles
- Policy-heavy models
- Manual approvals
Move toward:
- Control surfaces embedded in workflows
- Strong defaults and templates
- Built-in decision logic
⚙️ Practical Shifts Make the safe path the fast path
- Reduce steps and approvals
- Use templates and predefined structures
- Enable standard actions in minutes—not days
Create governance zones
- Low-risk → fast & flexible
- Medium-risk → structured
- High-risk → controlled
Design for AI and agents
- Treat AI as exposure amplification
- Govern agents like users (identity + access)
- Focus on data readiness—not just rollout
⚡ The 30-Day Move Pick one critical governance flow:
- Team creation
- External sharing
- Workspace provisioning
Then:
- Measure friction (time, steps, approvals)
- Identify bypass behavior
- Redesign for:
- Speed
- Clarity
- Embedded control
If it’s faster to follow the rules than to bypass them, governance starts working.
🎯 Who This Episode Is For
- CIOs and IT leaders scaling Microsoft 365
- Architects designing governance models
- Security & compliance leaders dealing with AI exposure
- Transformation leaders facing workflow friction
- Anyone whose governance works on paper—but fails in reality
💡 Final Thought
Governance is not the brake on innovation. It’s the operating system for trust, speed, and scale. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.
Transcribed
13 APR 2026 · In this episode, you’ll learn why Microsoft 365 GRC maturity is widely misunderstood and why it cannot be achieved through more policies, tools, or administrative effort. You’ll understand how true maturity is defined by predictable governance behavior and how your environment reveals its real state through audit performance, data exposure, and AI readiness.
- why maturity is not about policies, licenses, or dashboards
- how predictable governance behavior defines real maturity
- why audit time, exposure, and Copilot readiness reveal your true level
This episode is ideal for architects, consultants, IT leaders, and security professionals working with Microsoft 365, governance, compliance, and AI adoption.
M365 MATURITY IS NOT A FEATURE
Most organizations believe maturity comes from adding more controls, more policies, or upgrading to premium licensing. But across 500 tenants, the pattern is clear: maturity is not defined by what exists on paper, but by how the environment behaves under pressure. Two organizations can have the same tools and produce completely different outcomes. The difference is not capability — it is consistency.
WHAT MATURITY REALLY MEASURES
From a system perspective, maturity is the ability to produce consistent, measurable, and repeatable outcomes. It is not about implementation, but operationalization. A control that exists but is not used, measured, or enforced does not create maturity. True maturity means the right behavior happens by default, ownership is clear, and evidence is available without reconstruction.
THE FALSE SIGNALS OF MATURITY
Leaders often rely on signals that feel strong but do not reflect reality. Written policies, premium licenses, completed training, dashboards, and large control catalogs all create the appearance of maturity. But none of these guarantee that governance works under pressure. These are comfort signals, not performance indicators.
THE MATURITY MODEL
Level 100 is reactive governance, where control only appears when pressure arrives and everything depends on people.
Level 200 is managed but fragile, where processes exist but rely heavily on coordination and manual effort.
Level 300 is defined but uneven, where standards and metrics exist but consistency is not guaranteed.
Level 400 is predictable governance, where controls are automated, ownership is executable, and evidence is continuously produced.
Level 500 is optimized governance, where the system continuously improves and aligns governance with business strategy.
THE 5-QUESTION MATURITY CHECK
You don’t need a large assessment to understand your maturity. Ask five questions:
Do you have clear ownership for critical data and workspaces?
Do you know your sensitive data coverage?
Are your controls automated or manual?
Can you produce audit evidence in days instead of weeks?
Does your system make the right behavior the easiest path?
The answers reveal your real maturity instantly.
AUDIT TIME AS A SIGNAL
Audit preparation is one of the clearest indicators. Low-maturity environments need weeks to reconstruct evidence. High-maturity environments produce it within days because it already exists. Audit pain is not an audit problem — it is an operating model problem.
DATA EXPOSURE IS A DESIGN PROBLEM
Oversharing is rarely caused by user behavior alone. It is usually the result of broad permissions, weak labeling, unclear ownership, and missing lifecycle controls. Exposure is a system outcome. Strong environments reduce risk through architecture, not awareness.
COPILOT REVEALS YOUR MATURITY
AI does not create new problems — it exposes existing ones. If your data is inconsistent and your permissions are unclear, Copilot will surface that immediately. AI readiness is therefore a direct reflection of your GRC maturity.
FROM COMPLIANCE TO BUSINESS REALITY
Maturity is not a compliance exercise. It directly impacts audit speed, exposure risk, and how effectively AI can be used. Low maturity creates friction and dependency on individuals. High maturity creates stability, trust, and business velocity.
ABOUT THE HOST
Mirko Peters is a Microsoft 365 architect, advisor, and host of the m365.fm podcast. He works with organizations across SMB and enterprise environments, helping them move from reactive governance to predictable, scalable operating models. His focus is on real-world outcomes — audit readiness, data protection, and AI enablement — driven by system design rather than compliance theory. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.
Transcribed
12 APR 2026 · Hello, my name is Mirko Peters — and I translate how technology actually shapes business reality. Most leaders believe that policies create control.
But in reality, policies only create intent. Behavior follows something very different.
It follows friction, defaults, and the immediate pressure to get work done. That gap is where Microsoft 365 governance starts to fail. Your policy can say one thing, while your environment quietly rewards speed, convenience, and shortcuts. And when Copilot enters the picture, it doesn’t fix that gap—it scales it across your entire organization. In this episode, we break down why governance built on written policy is fragile by design, why people are not the problem, and how to move toward structural compliance using Purview, DLP, and Copilot. If your governance depends on memory and goodwill, AI will simply automate your weaknesses.
📈 WHAT YOU WILL LEARN
- Why policies create intent—but not control
- The difference between written governance and system-enforced behavior
- How friction and defaults shape real user decisions
- Why Microsoft 365 amplifies weak governance models
- How Copilot exposes gaps in permissions, labeling, and structure
- What “structural compliance” actually means in practice
- How Purview, DLP, and labels work together as enforcement—not guidance
💡 KEY TAKEAWAYS
- Policies don’t execute—systems do
- Human memory is not a reliable control layer
- Oversharing and workarounds are system outcomes
- Friction always beats compliance under pressure
- Defaults define behavior more than documentation
- Copilot amplifies your existing governance design
- Strong governance reduces decisions instead of adding more
⚠️ CORE INSIGHT
Governance fails when it depends on people making the right decision in the moment. Because in real work:
👉 People optimize for speed, not policy If the safe path is slower or unclear,
the system will produce risky behavior—every time.
🧩 WHAT THIS EPISODE IS ABOUT
This episode breaks down the shift from:
👉 Policy-driven governance
to
👉 System-driven governance We explore how to redesign Microsoft 365 so that:
- Classification becomes automatic
- DLP acts in real time
- Permissions define boundaries
- Copilot operates inside trusted context
This is not about more rules. It’s about building an environment where the right behavior happens by default.
👥 WHO THIS IS FOR
- CIOs, CISOs, and IT leaders responsible for Microsoft 365
- Security & compliance teams working with Purview and DLP
- Architects designing governance and operating models
- Organizations preparing for Copilot and AI adoption
If your governance relies on policies, training, and awareness—this episode will challenge that model.
🎙️ ABOUT THE HOST – MIRKO PETERS
Mirko Peters translates how technology actually shapes business reality. He focuses on Microsoft 365 governance, security, and operating models—helping organizations move from policy-based thinking to systems that work under real pressure. Through M365 FM, he connects architecture decisions with business outcomes across:
- Microsoft Purview
- Entra (Identity & Access)
- Copilot & AI readiness
His core belief:
👉 Governance is not what you write. It’s what your system produces.
🎧 FINAL THOUGHT Policies feel like control. But if your system doesn’t enforce them,
they are just suggestions. And in Microsoft 365:
👉 The system always wins. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.
Supporters Club
5 NOV 2025 · Are your Microsoft Copilot logs silently exposing sensitive data? In this episode of M365.FM, we reveal how unmanaged Copilot activity logs can create serious compliance risks, storage bloat, and security blind spots in your Microsoft 365 environment.
What you will learn in this episode:
- Why unmanaged Microsoft Copilot logs are a hidden security and compliance risk
- - How to use Microsoft Purview to capture, audit, and control Copilot activity logs
- - Step-by-step: enabling auditing and setting precise scopes for Copilot log management
- - How to establish data retention strategies and automate log exports
- - How to limit access to sensitive Copilot logs and avoid common configuration mistakes
- - How to operationalize workflows and build repeatable discovery processes under pressure
- - Practical tips to take control of Copilot logs for accountability, peace of mind, and data protection
Whether you are a Microsoft 365 admin, security professional, or compliance officer, this episode gives you actionable strategies to stop data leakage through Copilot logs before it becomes a costly problem.
About the Host:
Mirko Peters is the host of M365.FM, a podcast dedicated to modern work, security, and productivity with Microsoft 365. With deep expertise in Microsoft cloud technologies, AI, and enterprise security, Mirko shares practical insights to help IT professionals and business leaders get the most out of their Microsoft 365 investment.
Subscribe to M365.FM for weekly episodes on Microsoft 365, Copilot, Power Platform, Microsoft Purview, and enterprise security best practices.
#MicrosoftCopilot #Microsoft365Security #CopilotLogs #MicrosoftPurview #DataProtection #ComplianceManagement #M365Admin #EnterpriseAI #CloudSecurity #M365FM Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.
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,...
show more
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.
show less
Information
| Author | Mirko Peters (M365 Consultant) |
| Organization | m365 Show |
| Categories | Tech News , Technology , How To |
| Website | podcast.m365.show |
| mirko.peters@m365.show |
Copyright 2026 - Spreaker Inc. an iHeartMedia Company
