Support Engineering Weekly

Why is Microsoft Dataverse so much more than a database? In this episode, Alex and Maya examine Dataverse as a managed application data platform and explore how metadata, security, APIs, storage, capacity, integration, analytics, governance, and application lifecycle management work together to support enterprise workloads.

The discussion follows what happens when a request reaches Dataverse and explains why the platform's layered architecture changes how engineers should think about schema changes, metadata, standard versus custom tables, storage models, capacity planning, and security. The episode also examines the difference between operational and analytical workloads, API service protection limits, HTTP 429 responses, backoff, bounded concurrency, idempotency, and the performance implications of synchronous plugins.

The conversation then moves into governance and ALM, including solutions, managed versus unmanaged changes, deployment discipline, and why direct production customization can undermine the integrity of the deployment pipeline. Finally, Alex and Maya look at the growing role of AI agents and why clean metadata, well-defined security, lifecycle repeatability, predictable capacity, and resilient integrations become even more important as Dataverse becomes an operational data foundation for AI-enabled workloads.

The central lesson is straightforward: Dataverse should be engineered as a governed application platform, not treated as an isolated database.

This episode is based on the Support Engineering Blog article “Dataverse Isn't Just a Database”, including its layered architecture, metadata model, storage and capacity guidance, security model, integration patterns, ALM principles, and supporting diagrams.

Chapters

00:00 - Dataverse Isn't Just a Database

02:00 - The Six-Layer Dataverse Architecture

04:28 - Metadata as the Platform Contract

07:00 - Storage Engines and Capacity

11:12 - The Seven-Layer Security Gauntlet

14:48 - APIs, Analytics, and Throttling

18:09 - Plugins, Governance, and ALM

20:50 - Dataverse Anti-Patterns

22:12 - AI and the Platform Contract

Learn more:

The full technical article, references and supporting resources are available through the Support Engineering Blog at https://blog.sadhan.ch/.

This week on Support Engineering Weekly, Alex and Maya examine a series of Microsoft 365 incidents that reveal a common engineering pattern: as cloud services become more deeply connected, failures increasingly occur in the connective tissue between systems rather than in the systems themselves.

The episode begins with Microsoft’s transition from SharePoint One-Time Passcodes to Microsoft Entra B2B for external sharing, and what that means for legacy sharing links, guest identities, Conditional Access, and help-desk preparation. From there, the discussion moves into Teams device-management consolidation, iOS enrollment failures, and a Windows Autopilot routing issue where an internal network change caused seemingly unrelated device-management operations to fail.

The deeper dive focuses on Microsoft 365 Copilot, including licensing failures, agent deployment problems, traffic-related capacity issues, and a particularly significant semantic-indexing gap that left Exchange Online email available in storage but absent from Copilot's semantic understanding. The episode then turns to traditional Office clients, examining a Word PDF-save failure that redirected files into a hidden legacy cache location, an Exchange Online add-in synchronization issue, and a Teams workflow regression involving run-only permissions.

The common thread is silent and indirect failure: systems can appear healthy while an underlying dependency, routing path, synchronization pipeline, or indexing process is no longer behaving as expected. For support engineers, that raises a difficult question for the AI era: how do you troubleshoot a system that is functioning normally while quietly operating on incomplete information?

Chapters

00:00 - Cloud Dependencies Under Stress

01:47 - SharePoint External Access Changes

05:43 - Teams Device Management Consolidation

06:43 - Intune Routing and Autopilot Failure

10:03 - Copilot Licensing and AI Index Gaps

13:02 - Copilot Scale and Agent Failures

14:05 - Office Clients and Cloud Dependencies

16:44 - Exchange Add-ins and Teams Workflows

19:28 - The Enterprise AI Monitoring Challenge

Learn more:

Visit the Support Engineering Blog at https://blog.sadhan.ch/ for the full articles, technical references, and additional support-engineering resources behind the discussion.

A Power Automate flow can start as a simple productivity shortcut and quietly become business-critical production software. In this episode, Alex and Maya examine what changes when automation has to operate reliably at scale, including workload management, concurrency, downstream limits, retries, error handling, observability, ownership, application lifecycle management, and architectural boundaries.

The discussion begins by reframing a production flow as a small distributed system rather than a simple sequence of actions. Alex and Maya explore the multiplication problem, why broad triggers and loops can generate far more work than the flow designer suggests, and why increasing concurrency can simply move a bottleneck downstream. They then examine throttling, HTTP 429 responses, service protection limits, dynamic backoff, safe retries, stable business keys, and idempotent operations.

The episode then moves into production engineering practices: explicit failure paths using scopes and run-after conditions, actionable observability with Application Insights and KQL, service-principal ownership, managed solutions, environment variables, connection references, and modular flow design. The conversation also examines when Power Automate should hand work off to Azure Functions, desktop flows, or message queues instead of trying to perform every task itself.

Finally, Alex and Maya distinguish deterministic workflows from agentic workflows and explore how AI agents can complement governed automation when reasoning is required without replacing the predictable execution boundaries of production systems.

The central lesson is straightforward: a production flow should be engineered for failure, observability, scale, and change—not simply designed to work when everything goes right.

This episode is based on the Support Engineering Blog article “When a Power Automate Flow Becomes Production Software”, including its production architecture model, runtime and performance guidance, resilience patterns, observability practices, ALM approach, modularity principles, and supporting diagrams.

Chapters

00:00 - From Simple Flow to Production Software

02:00 - The Three Planes of Production

03:43 - The Multiplication Problem

05:35 - Concurrency, Throttling, and Safe Retries

09:08 - Failure Handling and Observability

12:09 - Production Ownership, ALM, and Modularity

16:00 - Choosing the Right Architecture

18:00 - Deterministic Workflows and AI

20:08 - Engineer for Failure, Not Luck

Learn more:

The full technical article, references and supporting resources are available through the Support Engineering Blog at https://blog.sadhan.ch/.

This week on Support Engineering Weekly, we look beneath the surface of Microsoft 365 incidents and the hidden dependencies that make apparently simple failures difficult to diagnose. The discussion begins with Microsoft 365 Copilot licensing and routing failures, then moves into Purview policy behavior and audit-log issues that show how problems in administrative and compliance layers can affect the support experience.

From there, we examine regressions across Office clients and their cloud-connected services, including the interaction between Word, SharePoint, and Exchange state. The episode also looks at rollbacks as diagnostic evidence and at API routing and infrastructure migration, highlighting how changes beneath the visible product layer can produce symptoms that initially appear unrelated.

The broader theme this week is the changing role of the support engineer: understanding dependencies, distinguishing client symptoms from service-side causes, and using operational evidence to reconstruct what actually changed.

This episode is based on the Microsoft Service Health updates included in the weekly coverage window for September 21–25, 2026.

Chapters

00:00 - Hidden Cloud Dependencies

02:01 - Copilot Licensing and Routing Failures

06:45 - Purview Policy and Audit Logs

11:05 - Office Clients and Cloud Dependencies

15:53 - Word, SharePoint, and Exchange State

19:57 - Rollbacks as Diagnostic Evidence

20:25 - API Routing and Infrastructure Migration

23:59 - The Modern Support Engineering Mindset

24:48 - Final Thought: The Future of Offline

Learn more:

Read the full technical articles, references, and supporting resources on the Support Engineering Blog at https://blog.sadhan.ch/.

Why does the Microsoft Power Platform become difficult to support when Power Apps, Dataverse, and Power Automate are treated as isolated products? In this episode, Alex and Maya examine the Power Platform as an architecture, with clear responsibility boundaries between the user experience, governed business data, orchestration, integration, compute, analytics, and the control plane.

The discussion explores deliberate handoffs between Power Apps, Dataverse, and Power Automate, the event-driven pattern that connects them, why Dataverse should be treated as shared business context rather than simple storage, and why specialized compute and analytics belong in the appropriate services instead of inside apps or flows.

The episode then examines enterprise control through environments, application lifecycle management, data loss prevention, and workload-level security. The conversation also looks at the 2026 direction of the platform, including Copilot, autonomous AI agents, and agentic low-code development, and explains why AI does not replace architecture. Instead, AI makes clear identity structures, governed data, security boundaries, integration controls, and proper ALM even more important.

The central lesson is straightforward: start with the workload, define clear responsibility boundaries, use deliberate handoffs, and treat the Power Platform as an integrated architecture rather than three separate products.

This episode is based on the Support Engineering Blog article “The Power Platform Isn't Three Products: It's an Architecture”, including its architectural model, responsibility boundaries, deliberate handoff pattern, Dataverse business context, integration and compute guidance, control-plane principles, security model, and supporting diagrams.

Chapters

00:00 - Three Products or One Architecture?

02:07 - Responsibility Boundaries

04:51 - Deliberate Handoffs and Events

07:57 - Dataverse as Business Context

10:28 - Integration, Compute, and Analytics

13:16 - The Control Plane and ALM

15:53 - Security Across the Workload

17:00 - AI Doesn't Replace Architecture

19:19 - The Workload-First Architecture Model

Learn more:

The full technical article, references and supporting resources are available through the Support Engineering Blog at https://blog.sadhan.ch.

This week on Support Engineering Weekly, Alex and Maya examine the Microsoft 365 Service Health events from September 14–18, 2026 through the lens of hidden dependencies and architectural complexity. The discussion begins with Microsoft 365 Copilot incidents, including retrieval failures caused by problems in semantic indexing and request-processing changes that affected multiple Copilot experiences.

The episode then moves into the administrative side of the stack, where telemetry and reporting failures created misleading data, audit logging problems removed critical user identity information, and seemingly simple desktop actions were affected by cloud-connected state. Excel copy-and-paste failures, Teams shared-channel links, and Outlook add-ins all demonstrate how tightly coupled modern clients have become with cloud services.

The final section looks at Defender XDR Conditional Access App Control and the security implications of infrastructure performance problems, including the trade-off between maintaining availability and maintaining security controls. The broader lesson is that support engineers can no longer look only at the visible symptom: accurate state, healthy data pipelines, dependency behavior, and security-layer performance are all part of understanding what a cloud service is actually doing.

This episode is based on the Microsoft Service Health updates for September 14–18, 2026 and the supporting technical material used for the episode.

Chapters

00:00 - Microsoft 365 Under Architectural Stress

02:24 - Copilot Search and AI Retrieval Failures

07:19 - Admin Reporting and Telemetry Blindness

10:17 - Audit Logs and the Non-Repudiation Gap

12:17 - Excel, Teams, and Outlook Regressions

16:52 - Defender XDR and Fail-Open Security

20:25 - The Invisible Foundations of Cloud Systems

21:23 - Final Thought: When AI Plays Dumb

Learn more:

The full technical source material, references, and supporting information are available through the Support Engineering Blog at https://blog.sadhan.ch.

Why can a user be blocked even when one Conditional Access policy shows a successful result? In this episode, Alex and Maya examine how Microsoft Entra evaluates Conditional Access and why a successful policy does not necessarily mean that access will be granted. The discussion explores the difference between a policy that did not apply and one that actually failed, how multiple applicable policies can combine requirements, and why troubleshooting requires finding the requirement that remained unsatisfied.

The episode then moves from the evaluation model into practical troubleshooting. Alex and Maya explore authentication strength, session controls, Authentication Context, the roles of What If, Report-only mode, and sign-in logs, and a six-step method for tracing an access failure from the exact sign-in event to its root cause. The goal is to replace guesswork and emergency policy changes with an evidence-first approach that fixes the actual cause while preserving the security posture.

The central lesson is straightforward: Conditional Access is a parallel evaluation, not a sequential checklist. Do not look for the policy that blocked the user; find the requirement that remained unsatisfied.

This episode is based on the Support Engineering Blog article “Why Is Conditional Access Blocking My User? A Systematic Troubleshooting Method”, including its troubleshooting method, policy evaluation model, root-cause guidance, investigation tools, and supporting diagrams.

Chapters

00:00 - Why a Successful Policy Can Still Mean Blocked

02:08 - Why Conditional Access Isn't a Firewall

05:15 - Applicability: Which Policies Actually Apply

11:04 - When Multiple Policies Stack Requirements

14:16 - Authentication Strength and Session Controls

17:26 - Authentication Context and Step-Up Access

19:12 - The Tools and Evidence That Matter

20:40 - The Six-Step Troubleshooting Method

23:07 - From Static Logs to Continuous Access

Learn more:

The full technical article, references and supporting resources are available through the Support Engineering Blog on the URL https://blog.sadhan.ch/,

This week on Support Engineering Weekly, Alex and Maya examine a set of Microsoft 365 incidents and updates that reveal just how deeply connected modern cloud services really are. A shared access configuration created a cross-service blast radius, while telemetry failures produced misleading reporting and downstream service behavior that turned incomplete data into real operational impact.

The discussion then moves into several targeted regressions across Outlook and Microsoft Teams, including unwanted Outlook add-ins, malformed shared-channel links, and failures affecting run-only workflows. The episode also looks at two very different forms of intentional disruption: an internal Microsoft resiliency drill that affected Copilot Chat suggestion pills, and TLS interception by network infrastructure that can make a customer-side security appliance look like a Microsoft cloud outage.

The episode closes with two Message Center updates administrators should prepare for: more granular Microsoft 365 Copilot usage exports and the upcoming Rewrite with Copilot feature in Edge for Business. Together, these changes highlight a broader support-engineering lesson: authentication, telemetry, network controls, and data-governance policies can all determine how cloud services behave at the user interface.

This episode is based on the Microsoft Message Center and Service Health updates for September 7–11, 2026, together with the supporting technical source material used for the episode.

Chapters

00:00 - Hidden Microsoft 365 Dependencies

02:03 - When the Access Layer Fails

05:37 - Telemetry Failures and Bad Data

11:04 - Outlook and Teams Code Regressions

15:17 - Copilot Drills and TLS Interception

18:26 - Copilot Analytics and Edge Rewrite

22:25 - Three Key Support Engineering Lessons

23:43 - Resilience in AI-Driven Interfaces

Learn more:

The full technical source material, references, and supporting information are available through the Support Engineering Blog at https://blog.sadhan.ch.

A Microsoft Entra sign-in log is more than a simple success or failure. In this episode, Alex and Maya examine how to read a sign-in event as an evidence trail, connecting identity, authentication, client and protocol, device, location, application, resource, Conditional Access, risk, status, error information, and correlation identifiers.

The discussion focuses on an evidence-first investigation approach: start with the exact sign-in event, understand what actually happened during authentication, identify the policies and requirements that applied, and connect the available evidence before reaching a conclusion. The episode also examines how the same sign-in data can be used proactively to identify patterns such as legacy authentication, repeated failures, Conditional Access anomalies, unusual device activity, and suspicious risk signals.

The central lesson is straightforward: don't just ask whether the sign-in succeeded. Ask what story the sign-in event tells you.

This episode is based on the Support Engineering Blog article “Microsoft Entra Sign-In Logs Explained: A Field Guide for Administrators and SOC Teams”, including its sign-in event model, investigation guidance, worked example, and supporting diagrams.

Chapters

00:00 - Read the Sign-In Differently

02:16 - Status, Errors, and Authentication

06:20 - Client, Device, and Location

08:40 - Application, Resource, and Policy

11:56 - Conditional Access and Session Controls

13:01 - Case Study: MFA Succeeded, Access Failed

15:24 - The Evidence-First Investigation

19:24 - From Troubleshooting to Threat Hunting

Learn more:

The full technical article, references and supporting resources are available through the Support Engineering Blog.

Why can a user successfully complete MFA and still receive an access-denied result? In this episode, Alex and Maya examine what happens after MFA succeeds and explain how Conditional Access, authentication strength, grant controls, device requirements, Authentication Context, and session controls can influence the final access decision.

The discussion focuses on an evidence-first troubleshooting approach: start with the exact sign-in event, identify which policies and requirements applied, determine what remained unsatisfied, and remediate the actual cause rather than weakening an unrelated security control.

The central lesson is straightforward: MFA success is evidence that one authentication requirement was satisfied. It is not evidence that the overall access decision must succeed.

This episode is based on the Support Engineering Blog article “Why MFA Success Can Still Result in Access Denied”, including its troubleshooting decision path, administrator checklist, and supporting diagrams.

Chapters

00:00 - Why MFA Can Succeed Yet Access Is Denied

04:28 - MFA vs. Authentication Strength

08:10 - The Multi-Requirement Minefield

10:14 - Finding the Failed Conditional Access Policy

11:31 - Authentication Context and Step-Up

13:40 - When Access Is Granted but Restricted

15:55 - The Evidence-First Troubleshooting Model

18:00 - The Conditional Access Troubleshooting Funnel

19:52 - Remediation Without Creating an Outage

20:45 - What If vs. Report-Only Mode

22:00 - Remediate the Requirement That Failed

23:01 - The Question Every Admin Should Ask

Learn more:

The full technical article, references and supporting resources are available through the Support Engineering Blog.