AI-Assisted Authoring: How Copilot, Canvas Apps Authoring MCP, and Playwright MCP Worked Together
The app scenario was intentionally simple: browse available devices, submit a purchase request, and review or cancel my own requests. That made it a useful test of the authoring workflow itself rather than a test of application complexity. The orchestration model The most important lesson was that each tool had a distinct role. The experience worked because the tools were not trying to do the same job. They handed work to each other at the right layer. GitHub Copilot in VS Code Interpreted my requirements, proposed the application plan and data model, coordinated the MCP tools, and guided the iterative implementation and troubleshooting process. Canvas Apps Coauthoring MCP Connected VS Code to the live canvas app, synchronized its source files, generated and updated YAML, compiled formulas, inspected data sources, and validated the app model. Playwright MCP Automated the authenticated browser experience in Power Apps Studio and the Power Apps Maker Portal. It handled interactions such as entering Copilot prompts, reviewing generated tables, wiring data sources through the user interface, and performing UI checks. Power Apps Copilot in the Maker Portal Provided a fast starting point for creating the Dataverse tables from a natural-language description, although the generated schema still required review and occasional correction. That separation mattered. Playwright MCP operated where an authenticated browser and user-interface interaction were required. Canvas Apps Coauthoring MCP operated where source code, schemas, formula compilation, diagnostics, and app-model validation were required. Power Apps Copilot accelerated Dataverse table creation, while GitHub Copilot served as the orchestration layer that connected my intent, the implementation plan, and the iterative fixes across all these surfaces. Starting from a real blank canvas app I began by enabling the canvas app coauthoring feature, opening a blank app in Power Apps Studio, and connecting Canvas Apps Authoring MCP from Visual Studio Code. The app stayed open in Studio, but the source became available locally as YAML. This created a practical split: I could reason and author in VS Code while still relying on the live Power Apps environment for authentication, metadata, data sources, and runtime validation. The initial app was the standard header, main, and footer template. From there, the AI-assisted workflow treated the app as an editable source project rather than a collection of manually inserted controls. Planning before generation Before generating screens, I used Canvas Apps Authoring MCP to drive the planning step. Instead of me hand-authoring every detail up front, the MCP helped translate the high-level idea - build a device purchase app - into a structured implementation plan. I then reviewed that plan, made a few tweaks, and approved it before generation started. That planning pass turned the request into a measurable target: the data model, screens, user actions, validation rules, and test scenarios. The approved Dataverse model included two tables: With that approved plan in place, Copilot and Canvas Apps Authoring MCP had a clear brief to work from. The workflow became less about guessing from a vague prompt and more about generating against a reviewed plan that could be compiled, validated, and adjusted. Using Playwright MCP for the browser-bound work Some parts of this build had to happen in the maker portal and Power Apps Studio. Because the browser session was already authenticated, Playwright MCP became the bridge into those experiences. It entered prompts into Power Apps Copilot, reviewed the generated table previews, corrected schema issues in the table designer, and added the Dataverse tables as data sources in the canvas app. This was not just UI automation for convenience. It let the AI-assisted workflow continue across surfaces that are normally difficult to drive from source alone: authenticated portal pages, embedded Studio frames, and generated Copilot previews. Where Copilot helped, and where it needed guardrails My first Copilot attempt asked for both Dataverse tables in one prompt, including fields, choices, lookup behavior, and autonumber requirements. Copilot produced a preview, but the operation stalled and the tables did not persist. The fix was to simplify the orchestration. Instead of asking Copilot to create the complete schema in one step, I created one table at a time. The Device table succeeded on the next attempt, including generated columns and sample records. After a short metadata delay and refresh, it appeared in Dataverse. Connecting Dataverse back into the canvas app After both tables existed, Playwright MCP opened the embedded Power Apps Studio frame and added the data sources: Devices and Device Purchase Requests. Canvas Apps Authoring MCP then inspected those sources from the app model. It confirmed that the sources were writable and delegatable and returned the logical names, data types, lookup metadata, and choice values needed for reliable formula generation. This handoff was critical. The browser created and connected the sources. The authoring MCP used the actual app metadata to generate formulas against the correct names rather than guessing. Building the app as source Once the data sources were available, Canvas Apps Authoring MCP generated the implementation plan, shared design rules, and per-screen briefs. The app was built as source and compiled repeatedly, not manually assembled control by control. The generated app included three primary screens: Device Catalog The catalog reads active device records from Dataverse and supports search by device name, manufacturer, or model; device-type filtering; stock visibility; and a Request action for active, in-stock devices. Purchase Request The request screen supports create and edit modes. It carries forward the selected device, calculates totals from unit price and quantity, and captures the business justification and needed-by date. My Requests The My Requests screen filters records to the signed-in user and supports reviewing, editing, and cancelling existing requests. Compile, diagnostics, and accessibility The compile step did more than check syntax. The first full compile produced 180 delegation warnings. Because the app was available as source, the assistant could inspect the repeated diagnostic pattern, identify the formula issue, update the affected expressions, and compile again. After the formula issues were resolved, App Checker reported no formula problems. Accessibility validation then found missing keyboard tab stops on both galleries. Adding TabIndex: 0 cleared those errors. This reinforced the value of treating validation as part of the authoring loop rather than a final manual cleanup task. How the Tools Worked Together The key was orchestrating the tools as one connected workflow rather than using each tool separately. The plan established the intent first. The app requirements, data model, screens, actions, and validation scenarios were defined before generating controls. Playwright MCP handled the authenticated browser tasks. It worked within the existing Power Apps browser session to prompt Copilot to create the Dataverse tables, review and correct the generated schema, and add the completed tables to the canvas app. Canvas Apps Authoring MCP created and validated the app. It inspected the connected data-source schemas, generated the app source and screens, compiled the Power Fx, diagnosed delegation issues, and supported the App Checker and accessibility validation loop. The maker orchestrated the complete process. I remained responsible for reviewing decisions, correcting the schema, coordinating the tools, and confirming that the final app matched the intended business experience. Final takeaway The biggest shift was where the time went. I spent less time inserting controls and rewriting formulas, and more time defining the user journey, reviewing generated decisions, correcting the data model, and validating behavior. Copilot provided a fast starting point. Playwright MCP extended the workflow into the authenticated maker experience. Canvas Apps Authoring MCP turned the canvas app into a source-driven project that could be planned, generated, compiled, inspected, and fixed from VS Code. Together, they created an orchestrated AI-assisted authoring loop rather than a one-shot generation experience. The result was a real Device Hub canvas app connected to Dataverse, compiled without formula errors or delegation warnings, and checked for accessibility. The tools moved quickly, but the solution still depended on human review, clear requirements, and validation at every handoff. Official documentation and further reading - Create and edit canvas apps with AI code generation tools - Microsoft Learn - https://learn.microsoft.com/power-apps/maker/canvas-apps/create-canvas-external-tools - Playwright MCP server for Power Platform testing - Microsoft Learn - https://learn.microsoft.com/power-platform/developer/playwright-samples/ai-mcp - View source code files for canvas apps - Microsoft Learn - https://learn.microsoft.com/power-apps/maker/canvas-apps/power-apps-yaml - Microsoft Playwright MCP server - GitHub - https://github.com/microsoft/playwright-mcp
Building Resilient Power Automate Flows That Stay Running
If you've spent any time working with Power Automate in enterprise environments, you've seen it happen. A business-critical flow fails on a Friday afternoon. The person who built it left the company six months ago. Nobody gets an alert. Nobody knows until Monday morning when someone notices the reports didn't run. By then, the blast radius is already bigger than it needed to be. Flow failures aren't inevitable, but unplanned ones usually share the same root causes: personal account dependencies, missing error handling, hardcoded configurations, and no visibility into what's actually happening at runtime. The good news is that most of these are solvable with patterns that aren't especially complex, they just require intentionality. This post covers 16 recommendations across 5 focus areas that I've found to be the highest-leverage investments for making Power Automate flows more resilient, performant, and easier to operate at scale. I've ordered them roughly by the impact you'll see fastest, with supporting documentation for each section for further reading and implementation guidance. 1. Credential and Connection Resilience This is where I always start with customers, because it's the most common source of outages and also one of the easiest to fix systematically. Migrate high-value flows to service principal ownership. Flows owned by user accounts fail when passwords change, MFA prompts fire, or the user leaves the organization. A service principal is a non-human identity that represents an application or service and doesn't have any of those human lifecycle problems. The pattern is to register an Azure AD app registration per workload domain, grant it the required API permissions, and bind the flow to it using connection references rather than a personal connection. For connectors that don't yet support service principals (SharePoint, Outlook, Teams), use a hardened service account protected with Privileged Identity Management. Service principal owned flows Service Principal Licensing Requirements Resolve broken connections Use connection references for all connections. Embedded personal connections break when flows are exported, imported, or the owner changes. If you're building flows inside solutions, there's no good reason not to be using connection references. Create one per connector type used in your solution and bind every flow to the reference rather than a personal connection. When you deploy through environments, you update the binding once rather than hunting through individual flows. Use connection references in solutions Pre-populate connection references for CI/CD Store secrets in Azure Key Vault, not flow variables. Hardcoded API keys or tokens in flow expressions show up in run history and are a real security exposure. The Key Vault connector has a "Get secret" action you can drop at the top of any flow. Restrict access to the service principal only, and when you rotate a secret in Key Vault, the flow picks it up dynamically with no changes needed. Azure Key Vault connector reference Key Vault secrets with environment variables Secure data in cloud flows 2. Error Handling and Retry Logic Unhandled errors in Power Automate produce silent failures. The flow shows red, maybe an email goes out if you're lucky, and whoever is on call has to play detective with limited context. Building proper failure boundaries before flows reach production is one of the highest-ROI things you can do. Wrap every action in a Scope with "Configure run after." A Scope action groups a logical block of actions and lets you branch on "Has failed." The pattern is straightforward: wrap each logical unit (get data, send notification, write to Dataverse), add a parallel branch configured to run on failure, and in that branch log the error, send an alert, and terminate cleanly. This keeps failure handling isolated and predictable rather than having it bleed across the entire flow. Use scopes to organize actions Best practices for using scopes Employ robust error handling Enable built-in retry policies on connector actions. Transient HTTP and connector errors are a fact of life. The retry policy setting on any connector action handles them automatically without custom logic. Exponential interval is generally preferable over fixed. Four retries with a PT10S interval is a reasonable starting point. One important caveat: check for idempotency before enabling retries on Dataverse writes, since a write that partially succeeded before a transient error can create duplicate records if blindly retried. Implement a retry policy Handle transient faults (Well-Architected) Flow limits & config (retry settings) Use "Do until" loops with exit conditions for polling. A polling loop without bounds can run indefinitely or silently miss the exit condition it was waiting for. Set a maximum iteration count and a timeout, and make sure your exit condition is the expected success state and not just the absence of error. Until logic documentation Flow limits: concurrency & looping Capture and surface error details in failure notifications. Generic failure emails like "Your flow failed" are nearly useless for triage. In the failure branch, use workflow().run.name and actions('ActionName')?['error'] expressions to pull the actual error message, and construct a direct link to the run using the environment name, flow ID, and run ID. Sending this as a Teams adaptive card with structured fields makes triage significantly faster than sifting through the admin center. Understand error codes 3. ALM and Environment Strategy Environment drift is sneaky. It builds up over time through ad-hoc edits made directly in production, hardcoded values that break on promotion, and manual export/import processes that are just inconsistent enough to cause problems at the worst times. Deploy only managed solutions to production. Unmanaged solutions in production allow anyone with access to make direct edits that bypass your ALM process. The model I recommend is straightforward: build in Dev with unmanaged solutions, export as managed for promotion, validate in Sandbox, and promote to Production through Pipelines. Use the "Block unmanaged customizations" setting in Environment security policies to enforce this at the platform level. Solution concepts with Power Platform Create and update custom solutions for ALM in Power Platform Use Power Platform Pipelines for automated promotion. Manual export and import is error-prone and doesn't scale. Pipelines automate the full Dev to Sandbox to Production path, support pre-deployment validation before each promotion, and let you restrict production deployment approvals to designated owners. If you're not using Pipelines yet, this is worth the setup investment. Overview of pipelines in Power Platform Set up pipelines in Power Platform Deploy pipelines as a service principal Eliminate hardcoding with Environment Variables. Flows that reference hardcoded SharePoint site URLs, list names, or IDs break every time they're promoted to a new environment. Replace them with environment variables, set the values at the environment level rather than in the solution itself, and validate bindings as part of your pre-deployment checklist. Environment variables for Power Platform overview Use environment variables in Power Automate solution cloud flows Apply DLP policies scoped per environment. Overly permissive DLP in production is a real risk for data leakage and flow instability. Classify connectors intentionally across Business, Non-Business, and Blocked. Scope policies from the top down, tenant-level first and then environment-level. Use endpoint filtering to restrict rather than wholesale block where possible, and always test DLP policy changes in Sandbox before promoting them to production. Data loss prevention policies overview Data policies for Managed Environments Identify blocked Power Automate flows from data policies 4. Monitoring and Observability If you don't have visibility into flow health, you're finding out about failures the worst possible way: from users. Most organizations have significantly less monitoring in place for Power Automate than they do for their traditional application workloads. Enable Power Platform admin center flow analytics. This is the quickest win in the monitoring category. In the Power Platform admin center, navigate to Analytics and enable flow run history and error reporting at the environment level. From there, set up a regular cadence (weekly is a good start) to review failure rates for flows classified as business-critical. Having that baseline gives you something to measure against when you start making resilience improvements. Tenant-level analytics Best practices for monitor your flows (analytics) Integrate with Application Insights for deeper observability. For environments running Managed Environments, you can configure the Data Export setting in the admin center to push cloud flow runs, triggers, and actions to an Azure Application Insights resource. Once data is flowing, you get full query and visualization capability for run health, custom diagnostics, and alerting. This is the right long-term destination for any organization that takes operational reliability seriously. Overview of integration with Application Insights Set up Application Insights with Power Automate 5. Performance and Throttling High-volume flows that aren't tuned for throttling will eventually hit API rate limits and start failing or queuing in ways that are hard to predict. Most of the common patterns here are straightforward to address. Apply concurrency control on trigger-heavy flows. By default, Power Automate concurrency is unbounded. A high-volume trigger can spin up thousands of parallel runs simultaneously and hit API limits quickly. Enable concurrency control on the trigger, set the degree of parallelism based on your connector's rate limits (starting between 10 and 25 is reasonable), and monitor queue depth in the Power Automate portal to tune from there. Understand limits & avoid throttling Flow limits: concurrency, looping, debatching Batch SharePoint and Dataverse operations instead of looping. An "Apply to each" loop that makes an individual API call per item scales linearly in both API call count and runtime. For SharePoint, use the "Send an HTTP request to SharePoint" action with OData $batch to group reads and writes. For Dataverse, use batch actions or FetchXML to pull multiple records in a single call. As a rough target, if a loop is making more than 50 individual API calls per run, it's a good candidate for batching. Make batch requests with the REST APIs - SharePoint Execute batch operations by using the Web API - Dataverse Use chunking for large file or record sets. Flows processing large payloads can hit the 100MB message size limit or simply time out. The pattern here is to split large workloads into pages using OData $top and $skip or Dataverse paging cookies, use a parent flow to orchestrate chunked child flows, and log progress state to Dataverse so the parent can resume if a chunk fails. Handle large messages in workflows using chunking in Azure Logic Apps (applies to Power Automate) Message size limits in Power Automate Where to Start If you're looking at this list and wondering where to begin, the recommended implementation order is: Credential and Connection Resilience first. This eliminates the most common source of outages. Migrate to service principals where supported and harden service accounts with PIM everywhere else. Error Handling and Retry Logic second. Low effort relative to the impact. Adding scopes, run-after branches, and retry policies is mostly configuration work, and the payoff is immediate. ALM and Environment Strategy third. Managed solutions in production, Pipelines for promotion, and environment variables in place of hardcoded values. Monitoring and Observability fourth. Structured logging and failure alerting gives you quantifiable before-and-after visibility on everything else you're doing. Performance and Throttling last. Address this for high-volume flows once the foundational reliability work is in place. You don't need to implement all 16 of these at once. Even getting the first two focus areas locked down will materially reduce the failure rate for most enterprise Power Automate implementations. The goal is to build flows that run reliably, fail visibly when something goes wrong, and don't require a forensic investigation every time they do. Start there and layer in the rest over time. Author: Marc Lotorto Contributors: Sheldon Dsouza, Ben Kohler
In a Day (XIAD) Partner Events Program - Train the Trainer Events (AgIAD, AIAD, AuIAD, PPIAD)
We invite you to attend an upcoming Train the Trainer session for Microsoft Partners to learn more about the In a Day (XIAD) Partner Events Program and how to lead workshops that empower customers to use and adopt Microsoft products. Our Train the Trainer events are designed to provide you with the knowledge and tools necessary to deliver successful Microsoft In a Day (XIAD) sessions. *Please note, participation is restricted to individuals representing a Microsoft Partner organization. You must register using your corporate email address that is associated with your Partner ID. Personal emails will not be approved. ✨ Why Attend? Expert Guidance: Learn from experienced trainers and get your questions answered. Comprehensive Resources: Access all the content and support you need to succeed. 📅 Upcoming Events: Agent in a Day Discover the basics of building agents with Microsoft Copilot Studio, including generative AI orchestration and integrating external data sources. Full day session (8 hours): Thursday, June 25 | 09:00–17:00 GMT+2 (Central European Summer Time) Trainer ready session (1.5 hours): Tuesday, June 30 | 09:00–10:30 GMT-5 (Central Daylight Time) Recordings available on-demand. Inquire at xiadevents@microsoft.com App in a Day Explore the fundamentals of building apps with Microsoft Power Apps, including creating custom business applications without writing code. Full day session (8 hours): Tuesday, June 23 | 09:00–17:00 GMT+2 (Central European Summer Time) Trainer ready session (1.5 hours): Tuesday, June 30 | 11:00–12:30 GMT-5 (Central Daylight Time) Recordings available on-demand. Inquire at xiadevents@microsoft.com Automation in a Day Explore automation solutions with Power Automate, including creating workflows and automating business processes. Trainer ready session (1.5 hours): Tuesday, June 30 | 14:00–15:30 GMT-5 (Central Daylight Time) Recordings available on-demand. Inquire at xiadevents@microsoft.com Power Pages in a Day Get hands-on building simple, secure business websites with Microsoft Power Pages. More sessions coming soon! Recordings available on-demand. Inquire at xiadevents@microsoft.com 👉 Register for all upcoming sessions at https://aka.ms/xiadTTT/pp Partner with us! Are you a Microsoft Partner interested in the opportunity to join the program and deliver In a Day (XIAD) events? 🔍 Learn more about the program and review partner eligibility criteria: https://aka.ms/xiadpartneropportunity. 📧 Contact the XIAD Program team: xiadevents@microsoft.com 🚀 Get started today: https://aka.ms/XIADGetStarted 📤 Submit requests to deliver events: https://aka.ms/xIAD/PartnerEventsPower Platform tenant inventory — a community showcase of the API-first management surface
Source: github.com/SweetsNSavories/VerseOps · MIT. Figure 1 — VerseOps loaded against a live tenant. Per-row capacity (DB / File / Log / FinOps DB / FinOps File GB) is computed from the BAP $expand=properties.capacity call; per-env asset counts are joined client-side from the Inventory API result set. Tenant identifiers redacted; everything else is real. Figure 2 — One environment row expanded. The row-details template fans out the inventory: Solutions / Apps / Flows / Agents (joined from the Inventory API and per-env Dataverse Web API calls), Power Pages sites (mspp_website table on the env's Dataverse), and the env's systemusers (with their assigned licenses joined from Microsoft Graph). All asset counts (9 / 3 / 53 / 241) are real. Figure 3 — Total Assets drawer (click the Total Assets KPI tile). The whole panel is fed by a single tenant-wide Inventory API query; the per-type counts are computed client-side from assetType. The "most recent" name surfaces the freshest asset of each kind so an admin can sanity-check that the tenant feed is current. Figure 4 — Licenses Consumed drawer (click the Licensed Users KPI tile). The list is the union of every assigned servicePlan from /users?$select=assignedLicenses rolled up to the SKU level using the tenant's subscribedSkus catalog from Microsoft Graph. SKU codes are public; the only tenant-specific data is the per-SKU seat count on the right. Why this exists The recurring questions at the start of every governance cycle are well known: "How many environments do we actually have? Who owns the apps in them? How much Dataverse capacity is sitting in places no one remembers creating? Which makers left the company three months ago and still own production flows?" The official answers — Power Platform admin center (PPAC), the Power Platform inventory page, and the Usage page — already exist and are the right starting point for daily work; they cover the common cases comprehensively. There are still moments, however, when an administrator needs: A single offline snapshot they can search, sort, filter, and ship to a stakeholder without exposing the live admin center. A diff between this morning and last Friday — what changed? Joined views that the portal doesn't ship out of the box: per-env capacity × per-env asset count × per-env user count, all in one sortable grid. The raw JSON behind every row, one click away, when something doesn't match what the portal shows. A starting point — code they can fork, instrument, and turn into the governance tool they actually wanted. VerseOps targets that long tail. The UI surface is roughly five files; every outbound call is enumerated in docs/network-endpoints.md. The codebase is deliberately small, read-only by design, and positioned as a foundation that adopting teams are expected to fork, instrument, and extend. How it complements the official "Inventory" and "Usage" pages Microsoft's Power Platform inventory gives administrators a unified view of agents, apps, and flows tenant-wide, refreshed within ~15 minutes. The Usage page tracks engagement and adoption. Both ship in the admin center today and should be every admin's first stop. VerseOps is positioned as a complement, not a replacement: Need PPAC Inventory / Usage VerseOps Daily inventory browsing in a portal ✅ Recommended n/a Filter / sort / search on any column ✅ ✅ Resource-detail drill-in (owner, env, dates) ✅ ✅ Export to Excel ✅ ✅ (CSV / cache copy) Capacity (DB / File / Log / FinOps GB) joined per env on the same row as asset count Partial ✅ One-click "show me the raw Dataverse / PPAC JSON" inspector ❌ ✅ Local SQLite cache for offline browsing on a plane / in an air-gapped review ❌ ✅ Diff between today's snapshot and yesterday's ❌ ✅ (cache-based, on roadmap) Source you can fork n/a ✅ MIT, single solution Telemetry sent to Microsoft / vendor per Microsoft's data policy None — zero outbound calls beyond Microsoft's own APIs If you only ever need 1–4 above, stay in the admin center; it's faster and always up to date. VerseOps shows up when you need 5–11. Architecture in one diagram Key architectural properties: Single process, no server-side footprint. Every call runs in the signed-in user's security context. There is no daemon, no sync job, no message bus. The operating system schedules the network calls; the user triggers a refresh. Two distinct cloud planes. Management-plane calls (api.powerplatform.com, api.bap.microsoft.com, graph.microsoft.com) are kept separate from data-plane calls ({org}.crm.dynamics.com per environment), with audience switching handled centrally by the auth layer. The local SQLite database is the only state. Removing %LOCALAPPDATA%\VerseOps\ returns the application to a blank slate. No other persistence exists. What's actually feasible with the Power Platform API today Microsoft has been very public about its shift from a UX-first to an API-first development model for Power Platform programmability: new capabilities ship in the API first, then propagate to SDKs, CLI, PowerShell cmdlets, and connectors. The Programmability and extensibility overview lays out the full toolchain — REST API, .NET SDK (Microsoft.PowerPlatform.Management), Python SDK, Power Platform CLI, PowerShell cmdlets, and the Power Platform for Admins V2 connector. VerseOps is a deliberately small showcase of what the .NET SDK + Inventory API combination unlocks once you put a UI on it: Capability API used SDK / endpoint List every environment in the tenant with name / region / SKU / version / security group / default-flag Power Platform API (PPAC) Microsoft.PowerPlatform.Management SDK Per-tenant capacity (DB / File / Log / FinOps DB / FinOps File GB) Power Platform API (PPAC) SDK Licensing.Tenant.GetCurrentCapacityAllocations() Per-environment capacity in one tenant-wide call BAP capacity (legacy GA) GET /providers/Microsoft.BusinessAppPlatform/scopes/admin/environments?api-version=2020-10-01&$expand=properties.capacity Every canvas app, model-driven app, code app, cloud flow, agent flow, and Copilot Studio agent in the tenant in one POST Inventory API (preview) POST https://api.powerplatform.com/resourcequery/resources/query?api-version=2024-10-01 (KQL-style query against PowerPlatformResources) DLP policies + connector classification (Business / Non-Business / Blocked) BAP Governance v2 GET /providers/PowerPlatform.Governance/v2/policies?api-version=2018-01-01 Per-env solutions / Power Pages sites / system users / roles / app + flow status Dataverse Web API v9.2 GET {org}/api/data/v9.2/solutions, appmodules, workflows, canvasapps, systemusers, mspp_websites User license SKU resolution + security-group display names Microsoft Graph GET /v1.0/subscribedSkus, /users, /groups, /directoryObjects/getByIds The headline shape of this: one tenant-wide POST replaces what used to be N×6 per-environment GETs. For a tenant with 700 environments, that's the difference between ~4,000 round-trips per refresh and ~10. The same Microsoft.PowerPlatform.Management SDK that powers the new admin-center surfaces is the same one your tooling uses — there's no longer a "fast official one and a slow community one". A note on the BAP API deprecation path Several BAP routes the community has relied on for years are now in a clear consolidation track rather than a deprecation one — but the destination is the same. From the official Versioning and support page: "The 2020-10-01 Generally available version of Power Platform API is specific to environment management and is also commonly referred to as Business Application Platform (BAP) API. The functionality of this set of endpoints are made available in the newer versions of Power Platform API along with many additional features after version 2022-03-01-preview." In practice, what this means for tools like VerseOps: BAP route VerseOps uses today Status (May 2026) Modern equivalent on api.powerplatform.com /scopes/admin/environments?$expand=properties.capacity GA (api-version=2020-10-01); functionally superseded but still recommended for tenant-wide capacity Will move to a Licensing namespace endpoint as parity completes; track Programmability what's new PowerPlatform.Governance/v2/policies (DLP) Stable Watch the new Connectivity / Governance namespace endpoints (e.g. List Connectors, shipped July 2025) Microsoft.BusinessAppPlatform provider routes All being mirrored under api.powerplatform.com namespaces (Licensing, EnvironmentManagement, AppManagement, Authorization, Governance, Connectivity) Use the SDK — Microsoft maintains the mapping for you Microsoft's official guidance is unambiguous: use the Power Platform API surface (api.powerplatform.com) and one of the official SDKs (.NET, Python, CLI, PowerShell, Power Platform for Admins V2 connector) for any new automation. BAP routes won't disappear without a deprecation cycle, but new features ship to api.powerplatform.com first and may never come back to BAP. VerseOps reflects this exactly: every new feature added since April 2026 went to api.powerplatform.com, the BAP capacity client is isolated to a single ~150-line file (BapCapacityClient.cs) so it can be swapped out the moment the per-env capacity surface lands on the new API, and the token-acquisition layer (AuthService.cs) supports both audiences side by side until that day comes. Who this helps The MIT license permits unrestricted internal adaptation; adopting teams are encouraged to fork, re-brand, and re-sign the binary with their own enterprise code-signing certificate as part of internal distribution. Typical adopters include: Power Platform administrators running quarterly governance reviews who need a single defensible snapshot of current tenant state. Center-of-Excellence (CoE) leads who previously relied on the CoE Starter Kit and are moving to the in-product Inventory + Usage pages, but still require a code-level surface to extend. FinOps and capacity owners identifying the ~5% of environments that consume 80% of Dataverse storage, with FinOps DB / FinOps File / Log GB visible on the same row as the environment name. Mission-critical and regulated workloads (financial services, healthcare, public sector) where a desktop tool that authenticates as the human administrator, emits zero telemetry, and stores all state locally is materially easier to risk-accept than a SaaS dashboard. Security and penetration-test teams who require a reproducible, auditable, signed Windows binary and a clear inventory of what it touches. The SBOM, SECURITY.md, SIGNING.md, and CodeQL workflow are committed to the repository. Engineering teams learning the Power Platform API who want a non-trivial, well-commented .NET sample that exercises every major namespace. Where this could go next The same API surface that powers VerseOps today can support a substantially richer set of experiences. Candidate directions follow; community input on prioritization is welcome via the issue tracker. 1. An agentic governance assistant Wrap the local SQLite cache + the same auth pipeline behind a Microsoft 365 Copilot agent (or a Foundry agent), and let an admin ask things like: "Which environments grew the most this week and who owns the new flows?" "List every canvas app with a deprecated connector that's still 'On' in a production env." "Show me orphaned resources owned by users disabled in Entra in the last 30 days." The Power Platform API + Inventory API already returns everything you need to answer these in seconds. The agent surface is just a new face for the same data — and because the cache is local, the agent can run without ever sending tenant data to a third party. 2. Periodic snapshots → drift report A scheduled task that runs VerseOps.App --refresh --headless once a day, writes the SQLite snapshot to a versioned folder, and emails a delta. "Today vs yesterday: +12 canvas apps in the Default env, –3 envs decommissioned, capacity climbed 4.1 GB on org-prod-eu." 3. Multi-tenant fan-out for MSPs / consultancies Same EXE, multiple tenant profiles, side-by-side comparison view. The auth layer already supports --tenant <guid>; the cache schema is per-tenant-keyed. 4. Plug-ins for the Inventory API custom queries The Inventory API's POST /resourcequery/resources/query accepts arbitrary KQL-style projections. A plug-in directory of "common admin questions as queries" (orphaned apps, oldest unused flows, premium connector usage by env) could grow organically. 5. Sister tools in Python / TypeScript The Python SDK is GA; a Jupyter notebook that mirrors VerseOps' three core panels (env list + capacity + assets) would be ~200 lines and would land instantly with the data-science crowd. The repository is intended as a working base for these explorations: the foundational ~80% — authentication, caching, paging, retry, redaction, error capture, and theming — is already implemented and exercised against a live ~700-environment tenant. Proposals for any of the directions above can be filed on the issue tracker. What's in the repository Everything below is on main at github.com/SweetsNSavories/VerseOps, MIT-licensed: The single WPF EXE — VerseOps.App/ API clients, one per Microsoft service — VerseOps.App/Inventory/Services/ SQLite catalog schema — VerseOps.App/Inventory/Sql/schema.sql README.md — install, run, build SECURITY.md — disclosure policy + threat model SIGNING.md — three publish-with-signature paths (self-signed dev, Azure Trusted Signing, OV/EV) docs/network-endpoints.md — every outbound host + OAuth scope THIRD-PARTY-NOTICES.md + sbom.cdx.json — full dependency attribution + CycloneDX SBOM CI: build, vulnerability scan, CodeQL — .github/workflows/ Branch protection ruleset (PR required, force-push blocked) — .github/branch-protection.json Try it git clone https://github.com/SweetsNSavories/VerseOps.git cd VerseOps dotnet build VerseOps.sln -c Release .\VerseOps.App\bin\Release\net10.0-windows\VerseOps.App.exe Sign in with a tenant admin account (Power Platform Administrator or Dynamics 365 Administrator), click Refresh, and the first cold pull populates the local cache. Subsequent launches are instant from the cache; click Refresh again whenever you want a fresh snapshot. Closing thought The thesis behind this post is straightforward: an API-first Power Platform management surface puts a complete tenant inventory within reach in roughly 3,000 lines of C#. The official Inventory and Usage pages remain the right tool for daily-driver scenarios. The SDK and Inventory API together cover the long tail — the cases where an organization needs a specific join, requires offline operation, or needs the answer the same week. VerseOps is offered to the community as that starting point. Issues and pull requests are welcome on the public tracker; security disclosures should follow the process documented in SECURITY.md. — Praveen T · maintainer, VerseOps References Power Platform inventory — the in-product surface VerseOps complements Power Platform admin center Usage page Programmability and extensibility overview — official tooling map Versioning and support — the BAP-vs-PPAC story Programmability — What's new or changed — monthly release log Power Platform API REST reference (latest) Microsoft.PowerPlatform.Management on NuGet — the .NET SDK VerseOps consumes Power Platform for Admins V2 connector — the no-code path to the same API Tutorial: Create a daily capacity report — Microsoft's own end-to-end SDK example Power Platform URLs and IP address ranges — for network allow-listsArchiving Years of Dataverse Audit History Before You Prune It — A Pragmatic, Open Source Pattern
Why the audit table is special The audit table is different from the rest of Dataverse in two ways that matter for an archive design: It’s an immutable, append-only record of who changed what, when, and from where — the closest thing Dataverse has to a forensic ledger. The valuable part of an audit row is not the row itself; it’s the diff (old value → new value, attribute mask, related-record context). The audit row stores that diff in a packed changedata column, and the bound RetrieveAuditDetails function is what decodes it into a structured OldValue / NewValue / ChangedAttributes shape your downstream tools can actually query. Synapse Link with the Delta Lake profile will carry the changedata column to the lake, but you still need a parser on the other side; this pattern calls RetrieveAuditDetails at archive-time so what lands in the destination is already decoded and immediately queryable. That combination makes the audit table the single most useful Dataverse table for: Regulatory and compliance investigations “Why did this opportunity status change in Q3 of 2022?” forensic queries (years after the fact) Internal analytics on user behaviour and process adoption It’s also the table that grows the fastest. The Dataverse default retention is 90 days, but in practice many enterprises extend that to several years — or set it to never delete — to retain evidence for compliance and forensic review. The result, often after five to seven years, is an audit table holding tens of GB to multiple TB of capacity, dominating the entitlement bill, and rarely accessed in normal operations. At that point the storage conversation becomes unavoidable. The realistic choices are: Keep buying entitlement. Predictable, but unbounded. Move the cold tail somewhere cheaper that you control, then let Dataverse’s audit-deletion job reclaim the space. The hot months stay in Dataverse where users expect them; the years of historical evidence live in your own storage account, queryable when you need them. This pattern is for option 2 — specifically, for the one-time bulk export of multi-year history, with the option to keep a slow trickle running afterwards if you want to top up. A crucial point that often gets lost: this pipeline does not need to run live. It is perfectly reasonable to be deliberately months or years behind real-time. The goal is to get a defensible copy of cold data out — the rows you are about to allow Dataverse to delete — not to mirror the audit feed in real time. What “good” looks like for an external audit copy Before showing any code, here’s the rubric I held this design to. If you build your own, hold yours to the same rubric: Property Why it matters Idempotent Re-running the same time window must not duplicate rows. Network blips happen. Crash-safe (exactly-once-effective) If the process dies mid-window, the next run must replay the same window cleanly. The watermark advances only after the data is durable in the destination. Bounded memory A backlog of millions of audits cannot be loaded all at once. Backpressure-aware Dataverse rate-limits aggressively. Throttle responses must not drop rows. Observable Every window logs [entity] mode=BACKLOG/LIVE, lag=Nmin, window=10min, records=N so you can watch it work. Sink-agnostic The “where does it land” decision is config, not code. Storage choices change; the orchestrator shouldn’t. Field-level discretion Audit details can carry PII. The pattern should let admins narrow which attributes leave the platform. The pattern The pipeline is conceptually four stages, repeated per entity, per time window: Three details in this picture do most of the resiliency work. They are deceptively simple: Detail 1: Half-open time windows (ge / lt) The boundary moment (09:10:00.000) belongs to window 2, not window 1. So adjacent windows never overlap and never gap, no matter how many times you replay. This is the same trick Kafka uses for offsets — it’s why you can run the loop with confidence. Detail 2: The destination document key is the Dataverse auditid GUID Dataverse already assigns a globally unique GUID to every audit row. That GUID becomes the document id in the sink. So when you upsert the same audit twice, the second write is a no-op overwrite of the first — idempotency for free, no client-side dedupe table to maintain. Detail 3: The watermark moves after the write, not with it The naive version of this pipeline does: The resilient version raises a typed exception when any record fails, and the watermark update is conditional on a clean write: This single change is the difference between “best effort” and “exactly-once-effective.” It’s also the mistake most often made when people roll their own. Choosing where it lands The orchestrator is sink-agnostic — it talks to a single AuditSink interface (get_state, update_state, write_audits) and the destination is a config switch, not a code change. The reference implementation ships with four production-shaped sinks plus a no-op for testing. None of them is the answer; they map to platforms enterprises already operate: Sink When to consider it Azure Cosmos DB (NoSQL API) Operational lookups — “show me everything user X did to record Y in 2022” in milliseconds. Hierarchical partition keys (/entity + /auditYearMonth) keep partitions small as the archive grows over years. Document TTL doubles as a retention policy if you want one. Serverless mode suits a slow-trickle archive workload. Azure Data Lake Storage Gen2 (Parquet) The cheap-cold-storage option. Years of audit history land as partitioned Parquet files (entity=…/year=…/month=…/), readable from Fabric notebooks, Synapse Serverless SQL, Databricks, or any Parquet engine. Costs scale with bytes, not throughput — ideal when the archive is rarely queried but must exist. OneLake (Parquet) Same Parquet shape as ADLS, but landed inside a Microsoft Fabric Lakehouse. Immediately queryable from a Fabric SQL endpoint, notebooks, and Power BI without further plumbing. The natural choice if your downstream BI is Fabric. Snowflake (MERGE INTO) The natural choice when Snowflake is already the analytics platform of record and adding a separate Microsoft analytics estate just for audit data isn’t on the table. MERGE INTO ... ON audit_id keeps the same idempotency contract as the Cosmos upsert, and the warehouse stays paused between archival batches. No-op (logs only) First-day connectivity testing. Confirms the Dataverse side works before you provision any storage. A reasonable default split many enterprises arrive at: ADLS Gen2 / OneLake (or Snowflake, if that’s your platform) holds the durable historical archive — cheap, partitioned, queryable when (rarely) needed. Cosmos DB holds the most recent N months for fast operational lookup if there is a use case for it; otherwise skip it entirely. Adding a sink for storage you already own (e.g., BigQuery, Redshift, on-prem object storage) is roughly 100 lines of Python and one factory entry. What real-world numbers will look like The worked test run above shows what a clean sandbox run looks like. Real numbers in your tenant will vary by orders of magnitude depending on: How many entities have auditing enabled The shape of RetrieveAuditDetails calls (more changed attributes per row = more bytes per call) Dataverse Web API rate limits applicable to your environment Concurrency you allow (max_concurrent_entities in the config) Sink throughput (Cosmos serverless RU autoscale, ADLS upload bandwidth, Snowflake warehouse size) The useful operational signal is not the absolute throughput — it’s that the throughput is stable and the per-window log lines tick predictably. If they don’t, look at lag, sink errors, or 429 responses from Dataverse before scaling up concurrency. When to reach for it (and when not to) Reasonable fit: You have multiple years of accumulated audit history in Dataverse and need to move the cold tail off the platform before pruning to reclaim entitlement. You want the decoded RetrieveAuditDetails payload (old value → new value, attribute mask, related-record context) landing in the destination ready to query — rather than the packed changedata column Synapse Link delivers, which still needs a parser on the consumer side. Your analytics platform of record sits outside Azure (most commonly Snowflake) and you don’t want to add Synapse + ADLS + Spark to your stack just to land the audit table. Synapse Link isn’t an option in your tenant — region pairing, governance review, or the cost floor of running ADLS + a Spark pool 24/7 don’t fit your environment. You’re comfortable running this as a batch job — once for the historical backfill, then perhaps quarterly or annually to top up — rather than as a live continuous feed. Being deliberately months or years behind real-time is fine and often desirable. You want field-level control over which attributes leave the platform — useful when audit details contain regulated data. Not a good fit: You can run Azure Synapse Link with the Delta Lake profile and you’re happy parsing the packed changedata column on the consumer side, and your destination is ADLS / Synapse / Power BI. That’s the supported, first-class path for the audit table — use it. You only need current state of business tables (account, contact, opportunity). Use Synapse Link / Fabric Link — they do exactly that and you don’t need this pattern. You need sub-second freshness in the destination. The pattern’s natural cadence is one window length (10 min in the reference config); for true real-time, use Dataverse webhooks or change-tracking APIs. You don’t have somewhere to operate a small Python container, function, or scheduled job — even an annual one. You don’t have an internal owner who can be paged when the schedule fails. The reference implementation The code that backs this post lives at https://github.com/SweetsNSavories/DataverseAuditLogSyn under MIT, with no warranty. The unified-deployment folder is the version this post describes — single Python codebase, swap sinks via config.json, runs locally / in a container / as an Azure Function. If you want the implementation depth this post deliberately leaves out — exact API shapes, watermark math, partial-failure drill, sink-author checklist, hosting variants, observability hooks, and the full list of operational responsibilities a self-hosted export carries — it all lives in one place: unified-deployment/DESIGN.md Issues, forks, and pull requests welcome via the repo. Generated 2026-05-14 from https://github.com/SweetsNSavories/DataverseAuditLogSyn/blob/main/docs/blog/archiving-dataverse-audit-logs.md · MIT licensed reference implementation, no warranty.
Service Principals in Microsoft Power Platform
Shared Passwords Are a Ticking Time Bomb Let’s be blunt: if your Power Platform automation runs on a shared service account password that three people know, you are one resignation away from every flow going dark, one password reset, one MFA change… That is all it takes. The fix? A service principal, a non‑human application identity in Microsoft Entra ID that authenticates with certificates, never logs in interactively, and keeps running no matter who leaves. In Power Platform, it shows up as an Application User in Dataverse and can own flows, manage Power BI datasets, run Dataverse operations, and power your CI/CD pipelines. Unlike a traditional shared service account (which carries the risk of password expiration, MFA prompts breaking automation, and credentials being overshared), a service principal authenticates using certificates or client secrets, has no mailbox, no interactive login, and cannot be accidentally used by a person. For organizations running Power Automate flows, calling APIs, running Power Platform Pipelines or managing environments programmatically, service principals offer a fundamentally more secure, auditable, and manageable identity. They enable least-privilege access, integrate cleanly with Conditional Access policies, and eliminate the single point of failure that comes with tying critical automation to an individual employee's account. This lack of tether to an individual account means workloads do not need to be reassigned once someone leaves your organization. Put more simply, if your Power Platform workloads are still running under a named user or a shared "svc_powerautomate@company.com" account, it's time to reconsider. Microsoft Advisory: “Best practice is to use service principals as the preferred identity model for Power Automate wherever supported, because shared user‑based service accounts introduce security, audit, and operational risks.” In this blog, we will highlight opportunities to strengthen your security posture across the Power Platform with Service Principals alongside ideas for when a Service Principal may not be applicable for your scenario. Getting Started: Setting up a service principal is straightforward. Everything is documented on Microsoft Learn: 🔗Register an app in Entra ID — Microsoft Learn 🔗Manage application users — Microsoft Learn 🔗Service principal owned flows — Microsoft Learn There are also many good blogs about step-by-step setup of the service principal, assigning permissions and assigning to an application user we won't be covering the setup here. Let's go into detail how you can utilize a Service Principal to secure your Power Platform workloads. Where Service Principals Shine in the Power Platform ⚡ Power Automate In Power Automate, service principals establish durable ownership and authentication for enterprise automation. Flows run under a non‑human application identity, eliminating dependency on individual users and preventing failures caused by password rotation, MFA enforcement, or user departure. Flow Ownership: Assign the service principal as the primary owner to ensure flows continue running regardless of personnel changes. Service Principal‑owned flows require either a Process license (~$150/flow/month, stackable up to 10 for 2.5M actions/day) or pay‑as‑you‑go billing via Azure. Authentication: Service principals authenticate using client credentials, removing the standard 90‑day connection expiry. Only the client secret or certificate has an expiration, which can be configured (up to 24 months). For production workloads, store secrets in Azure Key Vault with rotation alerts. Dataverse Connector: Dataverse is the only standard connector with native service principal sign‑in. Selecting Connect with Service Principal ensures all Dataverse actions execute under the application identity with full audit attribution. Non‑Service Principal Connectors: Connectors such as SharePoint, Outlook, and Teams require delegated user context by design. Where app‑only execution is required, the HTTP connector can be used to call Microsoft Graph with application permissions, introducing a premium dependency. ✓ Service Principal‑Friendly ✓ Microsoft Dataverse (native SP sign‑in) ✓ Custom connectors (app‑only OAuth) ✓ HTTP via Graph API (app permissions) ⚠ Requires User Context ⚠ SharePoint (standard connector) ⚠ Outlook / Office 365 ⚠ Teams (many actions) ⚠ Planner, OneDrive 🔗Support for service principal owned flows - Power Automate | Microsoft Learn 🔗 Manage connections to Dataverse — Microsoft Learn 📱 Power Apps and Dataverse Your Service Principal’s Application User executes Dataverse operations from flows triggered by model‑driven apps. Audit logs clearly separate automated changes from human activity. Assign custom security roles scoped to exact tables (skip System Admin), use separate Service Principalss per solution area, and know that canvas apps can trigger Service Principal‑backed flows behind the scenes. 🔗Create a Dataverse application user — Microsoft Learn 📊 Power BI This is where Service Principals quietly save organizations from one of the most common Power BI failures: dataset refresh breaking because the owner left. Take over semantic model ownership via the REST API and refreshes never fail from expired tokens again. Workspace access: add Service Principal as Member or Admin Semantic model ownership takeover via REST API Automated refresh from PowerShell, Logic Apps, Azure Data Factory, or custom apps XMLA endpoint access for model deployment and DAX queries (Premium/Fabric) App Owns Data embedding for external users without Power BI licenses Requirement: Tenant admin enables “Service principals can use Fabric APIs”. Service Principal added to workspace. API refresh needs Premium, Premium Per User, or Fabric capacity. 🔗Automate Premium tasks with Service Principals — Microsoft Learn 🔗Enhanced refresh REST API — Microsoft Learn 🛠️ Application Lifecycle Management (ALM) with Pipelines Power Platform Pipelines are a built-in option for application lifecycle management native to the Power Platform. Pipelines bring ALM automation and continuous integration and continuous delivery (CI/CD) functionality into a native service that's designed to be usable by all members of your low-code team, regardless of technical capability. To learn how to set up pipelines in Power Platform, Microsoft has some fantastic documentation as well as a learning path on Learn.microsoft to guide you through the process. We can utilize Service Principals in Pipelines as well. By default, a pipeline deploys as the requesting maker, meaning the maker needs elevated permissions to deploy to the target environment. Delegated deployments with Service Principals allow deployment without the maker needing elevated permissions in the downstream environment. The pipeline can run as a service principal (or pipeline stage owner), allowing makers to deploy without needing elevated permissions in target environments like production. Approvals may be required for security reasons, and can be automated or manual depending on your security requirements. 🔗PAC CLI: createserviceprincipal - Microsoft Learn 🛡️ Alternatives for Secure Workloads While service principals offer an avenue to securing most workload scenarios on the Power Platform, they cannot cover all workload scenarios. In these cases, there are alternative approaches. Azure Logic Apps support system-assigned and user-assigned managed identities, allowing workflows to authenticate directly to Azure resources without storing or managing any login credentials. This can offer an option when your workload can live outside Power Automate. Some teams opt to retain shared service accounts. This is not best practice, but when undertaken, there are steps to harden these accounts. Dedicated Entra Conditional Access policies to enforce MFA, restricting sign in locations and devices can provide additional protection. For password rotation, Azure Key Vault centralizes credential storage and enables automatic secret rotation, reducing the risk of stale or exposed passwords. Each of these approaches can be layered or combined with service principals depending on your organization's risk tolerance, licensing constraints, and connector support limitations. 🔗Governing Entra service accounts — Microsoft Learn All Your Options at a Glance Not sure which approach fits? Here is every option compared — from the gold standard to the fallback you hope to leave behind: Option MS Rec? Key Benefit Main Tradeoff Security SP + Process License Yes Gold standard. Certificate auth, clean audit. ~$150/flow/mo. Solutions required. Highest SP + Flow Groups Yes (GA May ’26) 1 license across up to 25 flows. Shared 250K/day action pool. Highest SP + Pay-as-you-go Yes Available today. No upfront cost. Variable cost. Azure sub needed. Highest Hybrid: SP + SA Pragmatic SP owns; SA for delegated connectors. SA still exists for connections. Med‑High Hardened SA Only No Simplest and no migration needed. Interactive login risk. MS discourages. Low Logic Apps + MI Yes (diff product) Zero credentials. Consumption billing. Full platform migration required. Highest ⚠ All costs are approximate and vary by enterprise agreement. Verify with your Microsoft representative. Microsoft‑validated: The dedicated service account fallback is a supported approach, not a workaround. Any alternative to service principals would need to be designed and accepted at the customer’s own risk. Summary Service principals replace shared, user‑based accounts with a non‑human application identity that is secure, auditable, and resilient. Eliminating password risk, improving governance, and ensuring Power Platform workloads continue running independent of employee lifecycle events across the entire platform. The result is higher security, operational stability, and governance consistency. The Bottom Line Service principals are not optional polish. They are how Microsoft expects you to run enterprise automation in 2026. One Entra ID app registration. Four products. Zero shared passwords. ✓ Blocking interactive admin logins is correct. No supported scenario requires it. ✓ Hybrid model when needed. Service Principals where supported, hardened service accounts where not. Both documented by Microsoft. ✓ Start with pay‑as‑you‑go. Pilot a batch. Measure costs. Then commit. No upfront purchase needed. Authors: Sheldon Dsouza + Marc Lotorto | Contributors: Rasha Al-Silmi, Ahmed Shaalan, Josh Flicker All guidance aligned with Microsoft Learn and validated by Microsoft Advisory, April 2026Breaking the Shackles of Legacy Portals: Power Pages as Enterprise SaaS
It's time to stop building "Portals" and start deploying Enterprise SaaS. For years, enterprise teams building web portals have been shackled by rigid Dynamics 365 schemas and heavy, template-driven UIs. Traditional Power Apps Portals required developers to follow the portal's own schema structure—page templates, web forms, lists, content snippets—and inherit data models dictated by D365 modules. That era is over. Power Pages has evolved into a secure, enterprise-grade, low-code SaaS platform for creating, hosting, and administering business websites—and as of early 2026, two milestone GA releases have removed the last remaining constraints. Here are six ways those shackles are broken: 🎨 1. UI Liberation with Single-Page Applications — Now GA Single-Page Application support in Power Pages reached General Availability on February 8, 2026, starting with site version 9.8.1.x and later. Developers can now build fully custom, client-side rendered web applications using React, Angular, or Vue and deploy them directly to Power Pages using the Power Platform CLI. This is not a workaround or a bolt-on—Microsoft describes this GA release as making the SPA experience "production ready". What this means in practice: the traditional portal constructs—ASP.NET and Liquid templates, web forms, lists—become optional implementation details, not architectural constraints. Your UI is completely custom and API-driven, calling Power Pages Web APIs for all data operations. The GA release also resolved issues where Power Pages platform styles could override custom CSS, and included updated guidance for authentication configuration and local development setup. Developers can run SPAs locally with full authentication and Web API access, enabling JavaScript hot reload and local debugging without deploying changes to the portal on every iteration. At this point, the traditional portal schema becomes an implementation option—not a constraint. (Ensure your Power Platform CLI is on the latest version for full capabilities.) 🗄️ 2. Data Model Autonomy — Your Entities, Your Rules Power Pages connects to Microsoft Dataverse, but you are no longer forced to borrow a Dynamics 365 schema. Teams can design their own data model from scratch—whether it has five tables or hundreds with complex relationships—tailored to the business domain. Those custom Dataverse tables serve the SPA directly via Web APIs, without needing to build model-driven or canvas apps. This is a fundamental departure. The platform uses the same shared business data stored in Dataverse that other Power Platform components can leverage, but your portal is no longer tethered to any pre-existing Dynamics module. You own your entity model entirely. The result: headless CMS flexibility backed by the security and reliability of Dataverse, without the overhead of a CRM schema you didn't ask for. ☁️ 3. Fully Managed Platform — No Infrastructure Burdens Goodbye, custom web hosting and plumbing. Power Pages is a fully managed SaaS platform—Microsoft handles provisioning, hosting, CDN, scaling, and availability. Authentication is built in, with full support for enterprise identity providers including Microsoft Entra ID and Microsoft Entra External ID, along with table permissions and web roles enforcement on every API call. Organizations can also allow anonymous access or configure private sites as needed. Even advanced backend needs are now covered natively. Server Logic in Power Pages reached General Availability on April 1, 2026, delivering native server-side JavaScript execution with the maturity, governance, and extensibility required for enterprise production workloads. Alongside GA, Microsoft announced two enhancements that reinforce enterprise readiness: Governance control to disable external calls — administrators can restrict outbound connectivity from the Server Logic layer to comply with internal policies and regulatory requirements. Support for unbound Dataverse custom actions — enabling deeper integration with existing business logic layers. The result? Teams focus only on business logic, integrations, and user experience. As Hope Bradford, Senior Director of IT at Kelly Staffing, stated: "Power Pages lets us build personalized client experiences without managing complex infrastructure while maintaining enterprise trust and security." Kelly Staffing's Helix UX portal, built on Power Pages, Dataverse, and Power Automate, now handles over 38,000 client interactions per day. 🛡️ 4. Enterprise-Grade Security and Telemetry Security and governance are first-class citizens on the platform. The 2025–2026 release wave introduced enterprise-grade controls for Power Pages including role-based access and authentication through Entra, Data Loss Prevention (DLP) rules for external data access, IP-based restrictions, maintenance mode options, and built-in diagnostics and monitoring dashboards. Across the broader Power Platform, Microsoft is investing in enterprise observability—the April 2026 update introduced alerting and data metrics in Power Platform Monitor (covering metrics such as app open success rate, time to interactive, data request success rate, and data request latency), enabling IT teams to define health thresholds, receive proactive notifications, and take guided action. This level of governance—audit, monitoring, diagnostics—traditionally required significant custom engineering. Now it is out of the box. 💲 5. Scalable, Usage-Based Licensing One of the most significant licensing shifts: Power Pages became its own product, decoupling from Power Apps licensing entirely. Both internal and external users now fall under the same licensing model, making Power Pages viable for internal use cases like HR services and request management—not just external portals. The model is usage-based (Monthly Active Users), purchased as capacity packs per site: Authenticated Users (Pre-paid): $200 per site/month for 100 users Anonymous Users (Pre-paid): $75 per site/month for 500 users Authenticated Users (Pay-As-You-Go): $4.00 per user/site/month, on-demand Anonymous Users (Pay-As-You-Go): $0.30 per user/site/month, on-demand Each authenticated-user subscription plan includes 2 GB database capacity and 16 GB file capacity. For applications serving tens of thousands of users, this capacity-based model is strategically superior to per-user or per-app seat licenses. Pay-as-you-go costs roughly twice as much as pre-paid capacity packs but suits seasonal or unpredictable usage patterns (e.g., tax season, annual HR enrollment). Tradeoff to consider: Pre-paid packs require upfront commitment and do not roll over month to month, so organizations with highly variable traffic must carefully model usage to avoid over- or under-provisioning. ⚠️ Pricing disclaimer: The figures above are illustrative examples sourced from publicly available Microsoft documentation. Actual costs may vary based on customer type (enterprise vs. corporate), volume commitments, negotiated agreements, and account structure. Final pricing is determined through Microsoft account teams and contracts. ⚡ 6. Rapid Modernization with AI-Assisted Development Power Pages now integrates directly with AI-assisted development workflows. Microsoft announced the public preview of the Power Pages plugin for GitHub Copilot CLI and Claude Code on February 24, 2026, providing an AI-assisted workflow for creating, deploying, and managing modern SPA sites on Power Pages. Developers can scaffold pages, configure data access, and wire up logic using natural language commands, dramatically reducing the time to modernize large enterprise applications. SPAs are deployed using Power Platform CLI commands, and the entire development loop is designed to be streamlined for professional developers. This means that even large, complex in-house enterprise applications—hundreds of tables, complex relationships, tens of thousands of users—can be remodeled on Power Pages far more efficiently than legacy approaches required. You migrate your own custom model into Dataverse, build your SPA, wire up integrations, and the platform handles everything else. The Bottom Line If you are still managing custom Azure websites, maintaining SQL servers, or stitching together bespoke PaaS stacks for internal business tools, you are carrying unnecessary operational weight. Power Pages is no longer just a D365 portal. It is a fully managed, enterprise-grade SaaS platform that gives you total UI freedom (SPA support: GA since February 2026), native server-side logic (GA since April 2026), your own data architecture without D365 schema dependencies, built-in security and governance, and a licensing model that scales to enterprise volumes. The industry is underestimating this shift. The shackles are off. Deploy, don't build.Token Cache Service Inside D365 CE Plugin Base
Introduction This document explores a performance optimization technique for Dynamics 365 plugins by implementing centralized token caching using static variables in a plugin base class. Since plugin instances are recreated for every request, holding variables in memory is not feasible. However, static variables—such as a ConcurrentDictionary—defined in a base class can persist across executions, enabling efficient reuse of authentication tokens. This approach avoids tens or even hundreds of thousands of daily calls to identity management endpoints, which can overload those services. Additionally, plugin execution time can increase by 500 milliseconds to one second per request if authentication is performed repeatedly. **Token caching is neither a universal requirement nor a general best practice; its value depends on whether small latency reductions meaningfully compound at scale and materially reduce repeated authentication traffic against the identity provider—conditions that most implementations do not experience**. 🔐 TokenService Implementation for Plugin Token Caching To optimize authentication performance in Dynamics 365 plugins, a custom TokenService is implemented and injected into the plugin base architecture. This service enables centralized token caching using a **static, read-only **ConcurrentDictionary, which persists across plugin executions. 🧱 Design Overview The TokenService exposes two methods: GetAccessToken(Guid key) – retrieves a cached token if it's still valid. SetAccessToken(Guid key, string token, DateTime expiry) – stores a new token with its expiry. The core of the service is a static dictionary: private static readonly ConcurrentDictionary<Guid, CachedAccessToken> TokenCache = new(); This dictionary is shared across plugin executions because it's defined in the base class. This is crucial since plugin instances are recreated per request and cannot hold instance-level state. 🧩 Integration into LocalPluginContext The TokenService is injected into the well-known LocalPluginContext alongside other services like IOrganizationService, ITracingService, and IPluginExecutionContext. This makes the token service available to all child plugins via the context object. public ITokenService TokenService { get; } public LocalPluginContext(IServiceProvider serviceProvider) { // Existing service setup... TokenService = new TokenService(TracingService); } 🔁 Token Retrieval Logic GetAccessToken checks if a token exists and whether it’s about to expire: public string GetAccessToken(Guid key) { if (TokenCache.TryGetValue(key, out var cachedToken)) { var timeRemaining = (cachedToken.Expiry - DateTime.UtcNow).TotalMinutes; if (timeRemaining > 2) { _tracingService.Trace($"Using cached token. Expires in {timeRemaining} minutes."); return cachedToken.Token; } } return null; } If the token is expired or missing, it returns null. It does not fetch a new token itself. 🔄 Token Refresh Responsibility The responsibility to fetch a new token lies with the child plugin, because: It has access to secure configuration values (e.g., client ID, secret, tenant). It knows the context of the external service being called. Once the child plugin fetches a new token, it calls: TokenService.SetAccessToken(key, token, expiry); This updates the shared cache for future executions. 🧱 Classic Plugin Base Pattern (Preserved) public abstract class PluginBase : IPlugin { protected internal class LocalPluginContext { public IOrganizationService OrganizationService { get; } public ITracingService TracingService { get; } public IPluginExecutionContext PluginExecutionContext { get; } public LocalPluginContext(IServiceProvider serviceProvider) { PluginExecutionContext = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext)); TracingService = (ITracingService)serviceProvider.GetService(typeof(ITracingService)); OrganizationService = ((IOrganizationServiceFactory)serviceProvider.GetService(typeof(IOrganizationServiceFactory))) .CreateOrganizationService(PluginExecutionContext.UserId); } } public void Execute(IServiceProvider serviceProvider) { try { var localContext = new LocalPluginContext(serviceProvider); localContext.TracingService.Trace("Plugin execution started."); ExecutePlugin(localContext); localContext.TracingService.Trace("Plugin execution completed."); } catch (Exception ex) { var tracingService = (ITracingService)serviceProvider.GetService(typeof(ITracingService)); tracingService.Trace($"Unhandled exception: {ex}"); throw new InvalidPluginExecutionException("An error occurred in the plugin.", ex); } } protected abstract void ExecutePlugin(LocalPluginContext localContext); } 🧩 TokenService Implementation public interface ITokenService { string GetAccessToken(Guid key); void SetAccessToken(Guid key, string token, DateTime expiry); } public sealed class TokenService : ITokenService { private readonly ITracingService _tracingService; private static readonly ConcurrentDictionary<Guid, CachedAccessToken> TokenCache = new(); public TokenService(ITracingService tracingService) { _tracingService = tracingService; } public string GetAccessToken(Guid key) { if (TokenCache.TryGetValue(key, out var cachedToken)) { var timeRemaining = (cachedToken.Expiry - DateTime.UtcNow).TotalMinutes; if (timeRemaining > 2) { _tracingService.Trace($"Using cached token. Expires in {timeRemaining} minutes."); return cachedToken.Token; } } return null; } public void SetAccessToken(Guid key, string token, DateTime expiry) { TokenCache[key] = new CachedAccessToken(token, expiry); _tracingService.Trace($"Token stored for key {key} with expiry at {expiry}."); } private class CachedAccessToken { public string Token { get; } public DateTime Expiry { get; } public CachedAccessToken(string token, DateTime expiry) { Token = token; Expiry = expiry; } } } 🧩 Add TokenService to LocalPluginContext public ITokenService TokenService { get; } public LocalPluginContext(IServiceProvider serviceProvider) { // ... existing setup ... TokenService = new TokenService(TracingService); } 🧪 Full Child Plugin Example with Secure Config and Token Usage public class ExternalApiPlugin : PluginBase { private readonly SecureSettings _settings; public ExternalApiPlugin(string unsecureConfig, string secureConfig) { // Parse secure config into settings object _settings = JsonConvert.DeserializeObject<SecureSettings>(secureConfig); } protected override void ExecutePlugin(LocalPluginContext localContext) { localContext.TracingService.Trace("ExternalApiPlugin execution started."); // Get token string token = AccessTokenGenerator(_settings, localContext); // Use token to call external API CallExternalService(token, localContext.TracingService); localContext.TracingService.Trace("ExternalApiPlugin execution completed."); } private string AccessTokenGenerator(SecureSettings settings, LocalPluginContext localContext) { var token = localContext.TokenService.GetAccessToken(settings.TokenKeyGuid); if (!string.IsNullOrEmpty(token)) { var payload = DecodeJwtPayload(token); var expiryUnix = long.Parse(payload["exp"]); var expiryDate = DateTimeOffset.FromUnixTimeSeconds(expiryUnix).UtcDateTime; if ((expiryDate - DateTime.UtcNow).TotalMinutes > 2) { return token; } } // Fetch new token var newToken = FetchTokenFromOAuth(settings); var newPayload = DecodeJwtPayload(newToken); var newExpiry = DateTimeOffset.FromUnixTimeSeconds(long.Parse(newPayload["exp"])).UtcDateTime; localContext.TokenService.SetAccessToken(settings.TokenKeyGuid, newToken, newExpiry); return newToken; } private Dictionary<string, string> DecodeJwtPayload(string jwt) { var parts = jwt.Split('.'); var payload = parts[1].PadRight(parts[1].Length + (4 - parts[1].Length % 4) % 4, '='); var bytes = Convert.FromBase64String(payload); var json = Encoding.UTF8.GetString(bytes); return JsonConvert.DeserializeObject<Dictionary<string, string>>(json); } private string FetchTokenFromOAuth(SecureSettings settings) { // Simulated token fetch logic return "eyJhbGciOi..."; // JWT token } private void CallExternalService(string token, ITracingService tracingService) { tracingService.Trace("Calling external service with token..."); // Simulated API call } } 🧩 Wrapping It All Together By combining these patterns into the base class–child class structure, we get a plugin framework that is: ✅ Familiar and extensible ⚡️ Optimized for performance with token caching 🗣️ Final Thoughts These patterns weren’t invented in a vacuum—they were shaped by real customer needs and constraints. Whether you're modernizing legacy plugins or building new ones, I hope these ideas help you deliver more robust, scalable, and supportable solutions.LTRDisplay Control - End-to-End Implementation and Usage Guide
1. Executive Summary LTRDisplay is a Power Apps Component Framework (PCF) control for model‑driven apps that helps users browse Long Term Retention (LTR) data in a familiar grid‑and‑form experience. GitHub SourceCode The control is designed for archive‑first usage in Dataverse: Fetch retained records with a selected view clause Replay cached data without refetching Open row details inside the same control Review audit changes and related records Minimize retained query calls through user‑local caching and lazy loading This document provides: Purpose and business value Solution design and architecture Import and validation steps Full user manual Repository fork and customization workflow 2. Purpose of the Control 2.1 Problem Statement Retention data is valuable for: Investigation Support Compliance Historical analysis However, users often require: Fast browsing of retained records Predictable filtering and navigation Minimal load on retained query infrastructure A form‑like experience for details, audit, and related data 2.2 LTRDisplay Objectives LTRDisplay addresses these needs by: Surfacing retained records directly in a model‑driven form Reusing Dataverse views/forms metadata for familiarity Introducing cache‑first interaction patterns Supporting drill‑down across related records in one panel 3. Solution Design 3.1 Runtime Design Main runtime behavior: Archive‑focused mode by default Selected view drives retained fetch clause Grid renders from cached projection Related records load only on explicit user action Detail form and tabs render from metadata and selected row payload 3.2 Core Components PCF shell: LTRDisplayControl/index.ts App state orchestration: LTRDisplayControl/components/App.tsx Grid and local filtering: LTRDisplayControl/components/DynamicGrid.tsx Metadata‑driven detail form: LTRDisplayControl/components/DynamicForm.tsx Dataverse access layer: LTRDisplayControl/services/LtrService.ts View/Form XML parsing: LTRDisplayControl/utils/XmlParser.ts 3.3 Cache Model Per‑user browser cache stores: View datasets Entity record dictionary by record id Related datasets Forms metadata Relationship metadata This enables: Show Cached behavior without server refetch Faster row‑open and navigation experience Reduced retained query consumption 3.4 UX and Interaction Model Fetch Archive button: calls retained fetch and updates cache Show Cached button: reads cache and applies local filtering Column filter flyouts: local filtering against projected rows Detail tabs: Summary Record Data Audit History Related Form switcher: choose available main forms for selected entity Chrome toggle arrows: hide/show header and command bar behavior 3.5 Security Intent LTRDisplay Main Form is intended for System Administrator users Role‑based form visibility should restrict exposure to non‑admin users 4. Solution Packaging and Import 4.1 Distributed Artifacts Latest packaged solution files: solution/LTRDisplay_managed_latest.zip solution/LTRDisplay_unmanaged_latest.zip Unpacked inspection artifacts: exports/unpacked_managed exports/unpacked_unmanaged 4.2 Import in Power Platform (Recommended Managed Path) Open target environment in Maker Portal Go to Solutions Select Import solution Upload solution/LTRDisplay_managed_latest.zip Complete import and publish customizations 4.3 Post‑Import Validation Checklist Validate the following: LTRDisplay Main Form exists and is enabled SystemUser form maps to ltr_LTRDisplay.LTRDisplayControl System Administrator can open the form Non‑admin users do not get the admin‑targeted form Fetch Archive returns retained rows Show Cached replays cached rows Record Data, Audit History, and Related tabs operate as expected 5. User Manual – Walkthrough Step 1 – Open form with control visible The form opens with Explorer – LTR and action controls. Step 2 – Toggle form chrome for focus Use the arrow controls to hide/show header and command bar. Step 3 – Start retained fetch Click Fetch Archive. During loading, controls can be temporarily disabled. Step 4 – Review fetched grid data Rows appear in the grid after retained fetch completes. Step 5 – Apply local column filter Open a column filter, enter a value, and apply the filter. Step 6 – Open a row into detail context Select a grid row to open detail section and tabs. Step 7 – Use form switcher Open the detail form dropdown and choose alternate form layouts when available. Step 8 – Inspect Record Data tab Review key‑value field output. Step 9 – Inspect Audit History tab Review: Changed by, Changed on, Operation, Old and New value. Step 10 – Use Related tab Select relationship and click Load to fetch related rows lazily. 6. Fork and Customize the Repository 6.1 Fork and Clone Fork the repository in GitHub Clone your fork locally Create a feature branch for your changes 6.2 Local Build Setup From repository root: npm install npm run build 6.3 Typical Customization Areas Most teams customize: App‑level behavior and UX flow components/App.tsx Grid columns and filter behavior components/DynamicGrid.tsx Detail tabs and rendering components/DynamicForm.tsx Dataverse query strategy services/LtrService.ts Styling and branding css/LTRDisplayControl.css 6.4 Push Changes to Dataverse (Development Loop) Use your existing PAC workflow in the target environment. Typical sequence: npm run build pac pcf push --publisher-prefix ltr --incremental pac solution publish 6.5 Export and Repackage After validation in environment: Export managed and unmanaged solution zips Update: LTRDisplay_managed_latest.zip LTRDisplay_unmanaged_latest.zip If needed, unpack for review under: exports/unpacked_managed exports/unpacked_unmanaged 6.6 Recommended Contribution Workflow Keep changes scoped by feature branch Run build before each push Capture screenshots for changed UX behavior Update docs in docs folder together with code Submit PR with: Short validation checklist Test evidence 7. Operational Notes and Best Practices Use managed package for consumer installation Keep unmanaged package for internal customization scenarios Treat retained fetches as expensive Prefer cache replay when possible Keep related loading on‑demand to control query volume Preserve role‑based visibility for admin‑focused forms 8. Conclusion LTRDisplay provides a practical archive exploration interface for Dataverse model‑driven apps with a strong focus on: Usability Cache efficiency Operational control By combining: Managed distribution Clear import validation A straightforward customization model Teams can adopt it quickly and evolve it safely for enterprise needs.Conditional Access for Canvas Apps with Entra
In today's Power Platform landscape, administrators have a tough task securing the ever-increasing inventory of Canvas Apps across their tenant. Canvas apps often connect to sensitive data, run on a variety of devices, and serve diverse groups of users. That is why Conditional Access has become one of the most powerful tools in an admin’s toolkit, giving you fine grained control over how, where, and under what conditions users can access your apps. In this post, I will walk through what Conditional Access means for canvas apps, how it empowers admins to maintain strong security without adding friction for legitimate users, and example steps to apply your own conditional access policies to an app with PowerShell. What Conditional Access Brings to Canvas Apps Conditional Access brings granular, app-level security controls from Microsoft Entra ID directly into Power Apps. Instead of applying blanket restrictions across the entire tenant, you can enforce requirements—like MFA, compliant devices, or trusted networks—only on the apps that need them. This lets you match security to the sensitivity of each individual app. Key Benefits for Admins Tailored Protection for Sensitive Apps Not every app requires strict controls. Conditional Access allows you to tighten security only for apps that handle sensitive or regulated data, without over restricting everything else. Control Access by Device Type Admins can easily block or allow specific device categories—like preventing mobile access to a high-risk app or requiring managed devices for apps that contain confidential information. Alignment With Zero Trust Conditional Access enforces identity, device, and session checks in real time, supporting a Zero Trust approach without adding unnecessary friction for legitimate users. Environment-Specific Flexibility You can apply stricter policies in production and lighter ones in development or testing, helping teams build efficiently while keeping sensitive environments locked down. A Stronger Security Model Conditional Access does not replace existing apps or data permissions—it complements them. App-level security roles control what users can do inside an app, while Conditional Access governs whether they can get into the app at all. Together, they create a much more robust security posture. How to enable conditional access for a Canvas App example In this example, I will detail steps to set up conditional access for a Canvas App to ensure tenant guest users are not able to access the app. Step 1: Create an Authentication Context in Entra ID Go to the Microsoft Entra Admin Center. Navigate to Protection → Conditional Access → Authentication context. Click + New authentication context. Name it (e.g., BlockGuests_PowerAppX) Enable Publish to apps Save and note the Authentication Context ID Step 2: Create a Conditional Access Policy Go to Conditional Access → Policies → + New policy. Name the policy (e.g., Block Guests from Power App X). Assignments: Users or workload identities: Include: Guest or external users Target resources: Choose Authentication context Select the one you created earlier Access controls: Grant: Select Block access Enable the policy and click Create. Step 3: Assign the Authentication Context to the Power App Use PowerShell to bind the Authentication Context to the specific Power App: Open PowerShell as Administrator. Connect to Power Apps Add-PowerAppsAccount Run the command to attach the context to your canvas app Set-AdminPowerAppConditionalAccessAuthenticationContextIds -EnvironmentName "<your-environment-name>" ` -AppName "<your-app-id>" ` -AuthenticationContextIds "<your-auth-context-id>" This binding tells Power Apps: “When this app opens, trigger the Conditional Access policy tied to this context.” Step 4: Test the Policy Try accessing the app as a guest user. You should see access blocked based on the Conditional Access policy. Wrap Up A Stronger Security Model Conditional Access does not replace existing apps or data permissions—it complements them. App-level security roles control what users can do inside an app, while Conditional Access governs whether they can get into the app at all. Together, they create a much more robust security posture. Bottom Line Conditional Access gives admins the flexibility to apply the right security to the right app. Whether you are enforcing MFA, restricting device types, or securing production environments, it helps you protect sensitive data without slowing down the organization. Documentation for further reading: Manage Power Apps - Power Platform | Microsoft Learn Demo from Power CAT: Conditional Access Policies for Canvas Apps - Power CAT Live
