What happens when a Power Platform app stops being a personal productivity tool and becomes an enterprise system that the business depends on?

In this episode of Support Engineering Weekly, Alex and Maya examine Power Platform governance from the perspective of operating applications safely at enterprise scale. The discussion begins with the transition from lightweight apps to critical business workloads and why governance needs to scale with the importance of the workload.

The conversation explores environments and the risks of allowing the default environment to become a universal development, test, and production boundary. From there, we examine proportional governance using business criticality, data sensitivity, external exposure, and lifecycle stage as dimensions for determining the appropriate governance posture.

The episode then moves into Data Loss Prevention and connector traffic, explaining how DLP policies control which data paths are possible and why DLP is only one part of the broader security model. Identity, environment access, Dataverse permissions, and least privilege are considered together with durable ownership, so critical workloads do not depend on a single individual.

We then examine application lifecycle management as governance in motion, including managed solutions, automated deployment pipelines, solution checks, environment variables, and repeatable production changes. Visibility and inventory are also discussed as prerequisites for governing a growing Power Platform estate.

Finally, Alex and Maya look at governance anti-patterns, time-bounded exception processes, and AI agents as another governed actor within the platform.

The central lesson is simple: governance is not about stopping innovation. It is about creating a safe, repeatable path for innovation to operate at enterprise scale.

Chapters

00:00 — When Apps Become Enterprise Systems

02:59 — Environments and the Default Trap

06:38 — Proportional Governance

09:53 — DLP and Data Path Control

13:26 — Security and Durable Ownership

16:50 — ALM and Automated Deployment

19:24 — Governance, Exceptions, and AI

Learn more:

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

Power Apps can make application development look simple - but what actually happens behind the screen when an enterprise application runs?

In this episode of Support Engineering Weekly, Alex and Maya look beyond the app interface to examine the engineering layers that make Power Apps work in an enterprise environment.

The discussion begins with choosing the right application model, including Canvas apps, model-driven apps, Power Pages, and Power Automate. From there, we follow the Power Apps runtime journey—from a user's action and Microsoft Entra authentication through Power FX, connectors, APIs, gateways, data sources, and the response that ultimately reaches the user.

We then examine delegation and why a query that works perfectly during development can become a serious scale problem when it encounters production-sized datasets.

The conversation moves into security, where application access is separated from actual data access. We explore the layers involved, including identity, environments, application permissions, connectors, roles, records, and column-level controls.

The episode also covers auditing, application lifecycle management, Data Loss Prevention, solutions, and managed deployment, showing why production readiness involves much more than getting an application to work.

Finally, Alex and Maya examine common enterprise anti-patterns—from non-delegable queries and unsuitable systems of record to excessive privileges, default-environment dependencies, and single-owner production workloads. The discussion also considers service principals, managed identities, licensing, and cost as part of the architecture itself.

The central lesson is simple: the app is not finished when it works. It is ready when it can be changed safely.

Chapters

00:00 — Power Apps: Behind the Screen

02:14 — Choosing the Right App Model

04:44 — The Power Apps Runtime Journey

07:24 — Delegation, Security, and Scale

12:10 — Auditing, ALM, and DLP

14:48 — Solutions and Safe Deployment

16:17 — Enterprise Architecture Anti-Patterns

Learn more:

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

A resilience update designed to make a service stronger can end up taking it offline. A routine cleanup can break a critical feature. And a small increase in response time can trigger a traffic surge that overwhelms an entire system.

In this episode of Support Engineering Weekly, Alex and Maya examine Microsoft 365 service incidents from October 5–9, 2026. They explore Outlook calendar caching failures and unwanted add-ins, cascading failures affecting Teams meetings and Copilot voice, request queuing and retry storms, and silent failures involving Teams contacts and PowerPoint Live recordings. The discussion also examines security and compliance issues involving Defender Conditional Access App Control, emergency calling, and legitimate DocuSign links being quarantined.

The episode concludes with a practical operational change: Microsoft’s migration of Teams Rooms on Android, Teams phones, and Teams panels management from the legacy Teams admin center to the Teams Rooms Pro Management Portal. Alex and Maya also consider a broader reliability challenge: how should engineers load-test generative AI workloads when prompt complexity and processing times are unpredictable?

Chapters

02:04 - Outlook Caching and Unwanted Add-ins

06:35 - Teams and Copilot Resilience Failures

09:01 - Cascading Traffic and Request Queues

12:47 - Silent Failures in Contacts and Recordings

16:31 - Security and Compliance Failures

21:01 - Teams Rooms Android Management Migration

22:51 - AI Load Testing and Cloud Reliability

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.

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.