Microsoft’s May 2026 Power Platform update, published May 14, makes Power Fx user-defined types generally available, expands Copilot-connected app experiences, adds context-aware generative pages, introduces AI-assisted InfoPath migration, and advances several modern Power Apps controls from preview toward production readiness. The release is not a single blockbuster feature so much as a signal that Power Platform is becoming more typed, more agent-aware, and more developer-adjacent. That matters because Microsoft’s low-code pitch is no longer just about letting business users build forms quickly; it is about making those forms governable, reusable, and ready to sit inside an AI-mediated workday.
The most important thing in this update is not the longest feature name or the flashiest Copilot demo. It is the way several unrelated-looking changes point in the same direction: Power Platform is being pulled toward the discipline of conventional software development while keeping the visual, maker-friendly authoring model that made it popular.
User-defined types in Power Fx are the clearest example. Low-code platforms often win adoption because they let people avoid the ceremony of “real” development, but that bargain gets expensive as apps become larger, longer-lived, and more connected to business-critical data. A canvas app that began as a quick departmental tool can become a dependency. At that point, weakly shaped data and ad hoc formula conventions stop being a convenience and start becoming technical debt.
By making Power Fx user-defined types generally available in version 3.26044, Microsoft is giving makers a way to name and enforce the shape of records and tables passed through their own functions. That sounds like a developer feature because it is. But it is also a low-code survivability feature: the bigger the estate, the more valuable it becomes to know that a “person,” “point,” “order,” or “approval” has a predictable structure.
The other half of the story is Copilot. Microsoft is not treating AI as a side panel that merely explains screens. It is building paths for apps to expose tools, UI widgets, and business logic directly into Microsoft 365 Copilot. That changes the role of a Power App from an interface someone opens to a capability an agent can invoke.
With UDTs, makers can define complex data structures using the
The immediate benefit is readability. A maker returning to an app months later can understand what a function expects without reverse-engineering every call site. The larger benefit is that app logic becomes easier to refactor because the shape of the data is named. In low-code environments, where many apps are built by people who are close to the business process but not necessarily trained developers, that extra structure is not an academic nicety.
The JSON angle may be even more consequential. Strong typing with
If Power Platform is to keep expanding beyond forms and workflows into agent-driven, multi-system orchestration, typed JSON is table stakes. AI can generate formulas and suggest mappings, but organizations still need deterministic validation. The model may help you write the expression; the runtime still needs to know whether a birthday is actually a date.
The new capability lets makers define custom MCP-powered tools that bring app-specific business logic into Copilot, along with Fluent-based UI widgets that can present insights and guide next steps. These tools integrate into the app’s MCP server and declarative agent, which lets Copilot orchestrate actions and combine data through natural language interactions.
That is the kind of sentence that can vanish into Microsoft platform jargon, so it is worth unpacking. The point is that a model-driven app can expose its domain-specific operations to an AI assistant in a structured way. Instead of a user asking Copilot a question and then manually navigating to the app to do the work, the app can provide callable tools and visual components that become part of the conversation.
This is not just a user-interface change. It is a power shift in application design. Traditional enterprise apps are built around screens: lists, forms, dashboards, commands, and navigation. Agentic apps are built around intentions: summarize this account, propose the next step, update this record, create a task, route the exception, show me why the pipeline changed.
The risk, of course, is that “agentic” becomes another marketing blanket thrown over ordinary automation. The preview status matters. Enterprises will want to know how these tools are permissioned, audited, versioned, tested, and constrained. A Copilot that can invoke business logic is useful only if admins can explain what it did after the fact.
This is a subtle change with a large surface area. Before this, generative pages were mostly standalone, top-level experiences launched from the sitemap. That made them visible but somewhat detached. They could be impressive, but they were not always where the work happened.
With context input, a generative page can be launched from a command bar button, a grid row action, subgrid navigation, or another in-app entry point. The page can then render the right experience based on the record or data passed into it. That turns generative pages from destinations into contextual extensions of existing workflows.
For administrators and app makers, this matters because enterprise software adoption is often won or lost in context switching. Users do not want to leave the record they are working on to ask a generic AI page for help. They want assistance that arrives with the customer, case, asset, ticket, or invoice already in view.
Microsoft still has gaps to close. Side pane support and placement as tabs or sections inside forms are not yet here, with Microsoft pointing to the next quarter for those scenarios. Until then, generative pages are more integrated than before, but not yet fully embedded in the places many model-driven app designers will want them.
The pitch is straightforward. Instead of opening each
This is exactly the sort of work AI coding agents are best positioned to accelerate. Legacy forms are often tedious rather than intellectually hard. They contain repetitive mappings, hidden assumptions, validation rules, submit behavior, and data connections that must be translated with care. An assistant that can inspect the artifact, produce a draft app structure, and let the maker iterate in natural language could save days or weeks across a large estate.
But migration is not modernization by default. An InfoPath form converted too literally into a canvas app may preserve every historical compromise. The value of the tool will depend on whether organizations use it as a first pass toward a cleaner Power Platform implementation or as a machine-speed way to carry old design problems into a new container.
There is also a governance angle. InfoPath forms often encode business logic that no current owner fully understands. AI-assisted migration can expose that logic, but it can also create a false sense of completion. Before a converted app goes live, someone still has to validate the rules, permissions, data sources, and user experience against the current process, not the process as it existed when the form was first built.
This may sound minor unless you have maintained a large canvas app. Workarounds pile up. A transparent button here, a nested container there, a formula to compensate for layout behavior somewhere else — each one adds fragility. When modern controls gain the properties makers expect, apps become easier to author and easier to debug.
The accessibility improvement is also not trivial. Icons with
The Dropdown control now uses a Fluent-themed flyout on desktop web instead of the browser’s native picker, giving apps a more consistent visual language. Button and Slider received improvements in border, padding, font parity, rendering, and visual states. These are not headline-grabbing features, but they are precisely the kinds of refinements that determine whether modern controls feel ready for default use.
Microsoft notes that one-click updates on old controls are not yet rolling out. That caveat matters. Modernization at scale is never just about shipping the new control; it is about giving organizations a safe path from old controls to new ones without breaking apps that may be business critical.
The Grid container introduces a modern, CSS grid-style layout model. Makers define rows and columns, then place child controls using row and column start and end positions, including spans. That can reduce the amount of container nesting and formula-driven layout gymnastics required to make screens responsive.
The GA release also includes the kind of authoring improvements that determine whether a layout system is merely correct or actually usable. Makers can drag controls into grid cells, resize controls with span handles, and use full undo and redo for drag and resize operations. Temporary overlap during repositioning removes an earlier friction point, and scroll-aware hit-testing helps when working inside larger grid layouts.
This is Microsoft borrowing from the web’s layout vocabulary while trying to preserve low-code direct manipulation. That is the right move. Responsive design should not require every maker to become a CSS expert, but neither can enterprise apps continue relying on pixel-by-pixel placement as their screens grow more complex.
For IT teams, the Grid container is another governance-adjacent feature masquerading as a design feature. Apps that use consistent layout primitives are easier to review, maintain, and hand off. They are also less likely to require emergency repair when a device, browser, embedding context, or accessibility requirement changes.
That is a necessary addition because business applications live and die by grids. Forms are important, dashboards are useful, and AI summaries are fashionable, but users still spend huge amounts of time scanning rows, sorting columns, selecting records, and taking batch actions. If Power Apps wants to replace or augment traditional line-of-business front ends, its grid story has to be strong.
The preview limitations are important. Attachment-type columns from Dataverse are not yet supported, and row virtualization for large datasets is not yet available. Microsoft says both are planned for the coming weeks, but until row virtualization lands, the “high-density” claim should be read with caution for large production scenarios.
Still, the direction is right. A Fluent UI grid with built-in search and selection is not just a convenience; it is part of making Power Apps feel like a first-class enterprise client rather than a collection of custom forms stitched together. The more these controls behave predictably, the less makers need to reinvent common UI patterns badly.
The challenge will be balancing simplicity with the expectations of power users. Enterprise grids quickly attract demands for filtering, grouping, export behavior, inline editing, conditional formatting, column persistence, keyboard shortcuts, and bulk operations. Public preview is the right place to start, but the road from “usable grid” to “beloved grid” is long.
Microsoft’s training updates are a map of where the platform is becoming more complex. New content around creating and editing canvas apps with AI code generation tools, enabling apps and custom tools in Microsoft 365 Copilot, generating MCP app widgets, using modern controls, and configuring Dataverse MCP suggests a platform that now expects makers to understand concepts that were once reserved for professional developers and platform engineers.
That has always been the tension in Power Platform. Microsoft sells empowerment, but enterprise deployment requires discipline. As the platform absorbs Copilot, MCP, typed formulas, generative pages, and AI-assisted migration, the skill floor for serious work rises even as the entry point remains friendly.
The result is a two-tier reality. Casual makers may still create useful apps with templates, drag-and-drop controls, and Copilot guidance. But organizations building durable systems on Power Platform will increasingly need environment strategy, ALM practices, security review, data modeling, accessibility testing, and an understanding of how AI-mediated actions are governed.
That is not a failure of low-code. It is what happens when low-code succeeds. The more important the apps become, the more they resemble software, and the more they need software-like practices around them.
That stack increasingly competes with the old pattern of local Access databases, Excel macros, SharePoint Designer workflows, InfoPath forms, and bespoke departmental utilities. Microsoft is not simply replacing those tools one for one. It is creating a governed cloud platform where those workloads can be rebuilt, monitored, and eventually exposed to agents.
The tradeoff is control. A local form or macro may be messy, but it is often understandable to the person who built it. A Power Platform solution connected to Copilot, Dataverse, MCP tools, and generative UI can be more powerful and more maintainable, but only if the organization has the governance maturity to match.
Sysadmins should care because shadow IT does not disappear when it moves to an approved platform. It becomes more scalable. A maker with access to connectors, AI generation, and business data can produce value quickly, but can also create compliance headaches quickly. The May update gives admins better building blocks, but it also widens the range of things makers can build.
Developers should care for a different reason. Power Platform is becoming less dismissible as “just low-code.” Typed functions, generated YAML, MCP servers, declarative agents, and AI coding workflows are developer-adjacent concepts. The platform is not replacing professional development, but it is increasingly overlapping with it in the messy middle where business apps live.
Source: Microsoft What’s new in Power Platform: May 2026 feature update
Microsoft Is Turning Low-Code Into Typed, Agentic Software
The most important thing in this update is not the longest feature name or the flashiest Copilot demo. It is the way several unrelated-looking changes point in the same direction: Power Platform is being pulled toward the discipline of conventional software development while keeping the visual, maker-friendly authoring model that made it popular.User-defined types in Power Fx are the clearest example. Low-code platforms often win adoption because they let people avoid the ceremony of “real” development, but that bargain gets expensive as apps become larger, longer-lived, and more connected to business-critical data. A canvas app that began as a quick departmental tool can become a dependency. At that point, weakly shaped data and ad hoc formula conventions stop being a convenience and start becoming technical debt.
By making Power Fx user-defined types generally available in version 3.26044, Microsoft is giving makers a way to name and enforce the shape of records and tables passed through their own functions. That sounds like a developer feature because it is. But it is also a low-code survivability feature: the bigger the estate, the more valuable it becomes to know that a “person,” “point,” “order,” or “approval” has a predictable structure.
The other half of the story is Copilot. Microsoft is not treating AI as a side panel that merely explains screens. It is building paths for apps to expose tools, UI widgets, and business logic directly into Microsoft 365 Copilot. That changes the role of a Power App from an interface someone opens to a capability an agent can invoke.
User-Defined Types Give Power Fx a Backbone
Power Fx has always occupied an unusual place in Microsoft’s stack. It borrows the approachable feel of Excel formulas, but it is asked to operate in scenarios that look increasingly like application engineering. The arrival of generally available user-defined types is therefore more than syntactic housekeeping.With UDTs, makers can define complex data structures using the
Type function in App.Formulas. In practical terms, this means a user-defined function can explicitly accept and return structured records and tables rather than relying on convention, inference, or repeated coercion. Microsoft’s example of defining a Point type and then using it in a distance calculation is simple, but the enterprise value is in less tidy examples: nested form payloads, approval objects, CRM fragments, asset records, and API responses.The immediate benefit is readability. A maker returning to an app months later can understand what a function expects without reverse-engineering every call site. The larger benefit is that app logic becomes easier to refactor because the shape of the data is named. In low-code environments, where many apps are built by people who are close to the business process but not necessarily trained developers, that extra structure is not an academic nicety.
The JSON angle may be even more consequential. Strong typing with
ParseJSON lets makers validate basic data types and convert values into Power Fx-native types. That matters because JSON is the connective tissue of modern automation. It appears in APIs, connectors, webhooks, and inter-service handoffs, and it is often where fragile apps break.If Power Platform is to keep expanding beyond forms and workflows into agent-driven, multi-system orchestration, typed JSON is table stakes. AI can generate formulas and suggest mappings, but organizations still need deterministic validation. The model may help you write the expression; the runtime still needs to know whether a birthday is actually a date.
Copilot Is Moving From Chat Window to Application Surface
Microsoft’s public preview of custom tools and rich UI for app-based conversations is a preview feature with a production-sized implication. It suggests that the future Power App is not merely something Copilot can talk about. It is something Copilot can act through.The new capability lets makers define custom MCP-powered tools that bring app-specific business logic into Copilot, along with Fluent-based UI widgets that can present insights and guide next steps. These tools integrate into the app’s MCP server and declarative agent, which lets Copilot orchestrate actions and combine data through natural language interactions.
That is the kind of sentence that can vanish into Microsoft platform jargon, so it is worth unpacking. The point is that a model-driven app can expose its domain-specific operations to an AI assistant in a structured way. Instead of a user asking Copilot a question and then manually navigating to the app to do the work, the app can provide callable tools and visual components that become part of the conversation.
This is not just a user-interface change. It is a power shift in application design. Traditional enterprise apps are built around screens: lists, forms, dashboards, commands, and navigation. Agentic apps are built around intentions: summarize this account, propose the next step, update this record, create a task, route the exception, show me why the pipeline changed.
The risk, of course, is that “agentic” becomes another marketing blanket thrown over ordinary automation. The preview status matters. Enterprises will want to know how these tools are permissioned, audited, versioned, tested, and constrained. A Copilot that can invoke business logic is useful only if admins can explain what it did after the fact.
Generative Pages Are Becoming Contextual Instead of Decorative
Generative pages are another place where Microsoft is moving from novelty toward workflow integration. The May update adds input support, allowing a generative page to open with context passed into it. That means the page can know which record, row, or scenario the user was working with when it launched.This is a subtle change with a large surface area. Before this, generative pages were mostly standalone, top-level experiences launched from the sitemap. That made them visible but somewhat detached. They could be impressive, but they were not always where the work happened.
With context input, a generative page can be launched from a command bar button, a grid row action, subgrid navigation, or another in-app entry point. The page can then render the right experience based on the record or data passed into it. That turns generative pages from destinations into contextual extensions of existing workflows.
For administrators and app makers, this matters because enterprise software adoption is often won or lost in context switching. Users do not want to leave the record they are working on to ask a generic AI page for help. They want assistance that arrives with the customer, case, asset, ticket, or invoice already in view.
Microsoft still has gaps to close. Side pane support and placement as tabs or sections inside forms are not yet here, with Microsoft pointing to the next quarter for those scenarios. Until then, generative pages are more integrated than before, but not yet fully embedded in the places many model-driven app designers will want them.
The InfoPath Migration Story Is Really About AI-Assisted Legacy Debt
InfoPath has been dead in product-strategy terms for years, but not in the places that matter most: corporate intranets, SharePoint libraries, compliance workflows, and departmental approval chains. The May Power Platform update takes aim at that long tail with the Canvas Authoring MCP Server and the PowerCAT Skill for InfoPath Migration.The pitch is straightforward. Instead of opening each
.xsn file, mapping every control, rebuilding each rule, and reconnecting every data source by hand, makers can use AI coding agents such as GitHub Copilot, Claude Code, or another MCP-compatible assistant to help migrate InfoPath forms into Power Apps canvas apps. The PowerCAT skill interprets InfoPath artifacts, unpacks the cabinet, parses XSN, XSF, and XSD definitions, and produces a structured representation of the form. The Canvas Authoring MCP Server then helps create controls, properties, formulas, and YAML for screens.This is exactly the sort of work AI coding agents are best positioned to accelerate. Legacy forms are often tedious rather than intellectually hard. They contain repetitive mappings, hidden assumptions, validation rules, submit behavior, and data connections that must be translated with care. An assistant that can inspect the artifact, produce a draft app structure, and let the maker iterate in natural language could save days or weeks across a large estate.
But migration is not modernization by default. An InfoPath form converted too literally into a canvas app may preserve every historical compromise. The value of the tool will depend on whether organizations use it as a first pass toward a cleaner Power Platform implementation or as a machine-speed way to carry old design problems into a new container.
There is also a governance angle. InfoPath forms often encode business logic that no current owner fully understands. AI-assisted migration can expose that logic, but it can also create a false sense of completion. Before a converted app goes live, someone still has to validate the rules, permissions, data sources, and user experience against the current process, not the process as it existed when the form was first built.
Modern Controls Are Finally Paying Down the Canvas App UI Tax
The May update also spends time on the less glamorous but highly practical work of modern controls. Button, Slider, Icon, and Dropdown are now described as GA-quality, with the Icon control gainingOnSelect support. That one property removes a common workaround: placing a transparent button over an icon just to make it clickable.This may sound minor unless you have maintained a large canvas app. Workarounds pile up. A transparent button here, a nested container there, a formula to compensate for layout behavior somewhere else — each one adds fragility. When modern controls gain the properties makers expect, apps become easier to author and easier to debug.
The accessibility improvement is also not trivial. Icons with
OnSelect now render with proper button semantics, including keyboard and screen reader behavior. That is the kind of detail that separates a demo-grade low-code app from something an organization can responsibly deploy to a broad workforce.The Dropdown control now uses a Fluent-themed flyout on desktop web instead of the browser’s native picker, giving apps a more consistent visual language. Button and Slider received improvements in border, padding, font parity, rendering, and visual states. These are not headline-grabbing features, but they are precisely the kinds of refinements that determine whether modern controls feel ready for default use.
Microsoft notes that one-click updates on old controls are not yet rolling out. That caveat matters. Modernization at scale is never just about shipping the new control; it is about giving organizations a safe path from old controls to new ones without breaking apps that may be business critical.
Grid Layout Is the Antidote to the X/Y Hangover
The Grid container becoming generally available is one of the most practically important Power Apps changes in the update. Canvas apps have long carried the legacy of absolute X/Y positioning, which is easy at first and punishing later. A screen that looks perfect on one device can become a maintenance trap when it needs to work responsively across form factors.The Grid container introduces a modern, CSS grid-style layout model. Makers define rows and columns, then place child controls using row and column start and end positions, including spans. That can reduce the amount of container nesting and formula-driven layout gymnastics required to make screens responsive.
The GA release also includes the kind of authoring improvements that determine whether a layout system is merely correct or actually usable. Makers can drag controls into grid cells, resize controls with span handles, and use full undo and redo for drag and resize operations. Temporary overlap during repositioning removes an earlier friction point, and scroll-aware hit-testing helps when working inside larger grid layouts.
This is Microsoft borrowing from the web’s layout vocabulary while trying to preserve low-code direct manipulation. That is the right move. Responsive design should not require every maker to become a CSS expert, but neither can enterprise apps continue relying on pixel-by-pixel placement as their screens grow more complex.
For IT teams, the Grid container is another governance-adjacent feature masquerading as a design feature. Apps that use consistent layout primitives are easier to review, maintain, and hand off. They are also less likely to require emergency repair when a device, browser, embedding context, or accessibility requirement changes.
Data Grid Preview Shows Microsoft Still Has a Density Problem to Solve
The new Data Grid modern control enters public preview as a Fluent UI-based answer to a familiar enterprise requirement: show a lot of tabular data without making the app feel like a toy. It supports searchable rows, sortable columns, multi-row selection, and configurable column sub-controls such as Text, Number, Phone, Email, URL, and Button.That is a necessary addition because business applications live and die by grids. Forms are important, dashboards are useful, and AI summaries are fashionable, but users still spend huge amounts of time scanning rows, sorting columns, selecting records, and taking batch actions. If Power Apps wants to replace or augment traditional line-of-business front ends, its grid story has to be strong.
The preview limitations are important. Attachment-type columns from Dataverse are not yet supported, and row virtualization for large datasets is not yet available. Microsoft says both are planned for the coming weeks, but until row virtualization lands, the “high-density” claim should be read with caution for large production scenarios.
Still, the direction is right. A Fluent UI grid with built-in search and selection is not just a convenience; it is part of making Power Apps feel like a first-class enterprise client rather than a collection of custom forms stitched together. The more these controls behave predictably, the less makers need to reinvent common UI patterns badly.
The challenge will be balancing simplicity with the expectations of power users. Enterprise grids quickly attract demands for filtering, grouping, export behavior, inline editing, conditional formatting, column persistence, keyboard shortcuts, and bulk operations. Public preview is the right place to start, but the road from “usable grid” to “beloved grid” is long.
The Training Updates Reveal the Real Product Strategy
The May blog closes with a long list of new and updated training content across Power Apps, Power Automate, Power Pages, administration, developers, and connectors. It is tempting to skip that section as routine documentation housekeeping. That would miss the point.Microsoft’s training updates are a map of where the platform is becoming more complex. New content around creating and editing canvas apps with AI code generation tools, enabling apps and custom tools in Microsoft 365 Copilot, generating MCP app widgets, using modern controls, and configuring Dataverse MCP suggests a platform that now expects makers to understand concepts that were once reserved for professional developers and platform engineers.
That has always been the tension in Power Platform. Microsoft sells empowerment, but enterprise deployment requires discipline. As the platform absorbs Copilot, MCP, typed formulas, generative pages, and AI-assisted migration, the skill floor for serious work rises even as the entry point remains friendly.
The result is a two-tier reality. Casual makers may still create useful apps with templates, drag-and-drop controls, and Copilot guidance. But organizations building durable systems on Power Platform will increasingly need environment strategy, ALM practices, security review, data modeling, accessibility testing, and an understanding of how AI-mediated actions are governed.
That is not a failure of low-code. It is what happens when low-code succeeds. The more important the apps become, the more they resemble software, and the more they need software-like practices around them.
The Windows Shop Should Read This as a Platform Shift, Not a Feature Dump
For WindowsForum readers, the Power Platform update is interesting less because it adds a new slider property and more because it shows how Microsoft imagines business software running across Microsoft 365, Dataverse, Copilot, and the browser. This is the modern Windows enterprise stack by another name: identity in Entra ID, data in Dataverse and SharePoint, automation in Power Automate, interfaces in Power Apps, and AI orchestration through Copilot.That stack increasingly competes with the old pattern of local Access databases, Excel macros, SharePoint Designer workflows, InfoPath forms, and bespoke departmental utilities. Microsoft is not simply replacing those tools one for one. It is creating a governed cloud platform where those workloads can be rebuilt, monitored, and eventually exposed to agents.
The tradeoff is control. A local form or macro may be messy, but it is often understandable to the person who built it. A Power Platform solution connected to Copilot, Dataverse, MCP tools, and generative UI can be more powerful and more maintainable, but only if the organization has the governance maturity to match.
Sysadmins should care because shadow IT does not disappear when it moves to an approved platform. It becomes more scalable. A maker with access to connectors, AI generation, and business data can produce value quickly, but can also create compliance headaches quickly. The May update gives admins better building blocks, but it also widens the range of things makers can build.
Developers should care for a different reason. Power Platform is becoming less dismissible as “just low-code.” Typed functions, generated YAML, MCP servers, declarative agents, and AI coding workflows are developer-adjacent concepts. The platform is not replacing professional development, but it is increasingly overlapping with it in the messy middle where business apps live.
The Practical Reading of Microsoft’s May Power Platform Push
This update rewards a grounded reading. It is not a revolution delivered in one monthly blog post, and several of its most interesting pieces are still in preview. But the concrete direction is hard to miss: Microsoft is making Power Platform more structured underneath, more AI-addressable above, and more credible as a place to modernize the old forms-and-workflows estate.- User-defined types are now generally available in Power Fx version 3.26044, giving makers stronger structure for functions, records, tables, and JSON parsing.
- Custom tools and rich UI for app-based conversations are in public preview, extending model-driven apps into Microsoft 365 Copilot through MCP-powered tools and Fluent-based widgets.
- Generative pages can now receive input context, making them more useful from command bars, grid row actions, and other in-app entry points.
- AI-assisted InfoPath migration is emerging as a serious legacy modernization path, but converted apps still need human validation, redesign, and governance.
- Modern controls and the GA Grid container continue the slow but necessary work of making canvas apps more responsive, accessible, and maintainable.
- The new Data Grid preview is promising for dense business data, but large-dataset scenarios should wait for row virtualization before anyone declares victory.
Source: Microsoft What’s new in Power Platform: May 2026 feature update
Last edited:
