Power Apps Custom Tools and Widgets Now Power Copilot App Conversations

Microsoft has moved Power Apps deeper into the Microsoft 365 Copilot experience, and the latest public preview is more than a cosmetic upgrade. With custom tools and rich app-powered UI, makers can now shape conversational workflows that feel less like static Q&A and more like a guided business action inside Copilot. The announcement, published April 22, 2026, extends the earlier preview that let model-driven Power Apps appear inside Copilot conversations and adds a more flexible path for building tailored, interactive experiences.

Overview​

The significance of this release is that Microsoft is no longer treating Copilot as a general-purpose assistant bolted onto business apps. Instead, it is turning model-driven Power Apps into agent-ready surfaces with their own MCP server, built-in Dataverse tools, and now custom actions and widgets layered on top. That makes the app itself the unit of conversational intelligence, rather than a separate chatbot with a connector on the side.
That shift follows a clear product sequence. Earlier in April, Microsoft said business apps could show up in Microsoft 365 Copilot conversations through their MCP server, but custom tools were only promised for “the coming weeks.” This week’s preview closes that gap and adds a visual layer via widgets, which Microsoft says are self-contained MCP-compliant HTML files built on Fluent UI and designed to adapt to Copilot’s light and dark themes.
The architectural implication matters as much as the feature list. Microsoft is framing this as part of the broader Microsoft 365 Copilot extensibility platform, where agents, plugins, connectors, and MCP-based experiences can all live in the same ecosystem. In practice, that means Power Apps makers can build business logic and user interfaces that ride on Microsoft’s agent framework without standing up a separate service layer.
It is also an unmistakable signal about where Microsoft wants Power Apps to sit in the stack. Power Apps is no longer just a low-code app builder for forms, grids, and workflows. It is becoming a source of reusable business actions and a distribution point for conversational AI experiences across Microsoft 365, Teams, and the broader Copilot surface area.

Background​

Microsoft has spent the last year reshaping Power Platform around AI-assisted development and agentic workflows. Power Apps already supported Copilot features for app building, data exploration, and model-driven app experiences, and Microsoft has steadily been adding more app-level Copilot integration throughout 2025 and into 2026. The current preview is part of that longer arc, not an isolated experiment.
The immediate precursor came earlier this month, when Microsoft announced that model-driven Power Apps could participate in Microsoft 365 Copilot conversations. At that stage, users could interact with app data through Copilot, but the experience was still bounded by built-in app tools for querying, creating, viewing, and editing Dataverse records. The new release extends that foundation by letting makers author their own actions and tailor the UI to the task.
That distinction is important because the built-in app tools are useful but generic. They handle common CRUD-style interactions well, yet they do not solve domain-specific scenarios like surfacing a weighted case-flow visualization, generating a custom risk summary, or presenting a decision panel that maps directly to a business process. Microsoft’s preview is explicitly about those higher-order scenarios.

Why Microsoft is emphasizing MCP​

The repeated emphasis on MCP is not accidental. Microsoft is aligning its app extensibility story with the Model Context Protocol trend so that business applications can expose actions and UI in a standard way that Copilot can reason over. In the Microsoft 365 ecosystem, that also creates a bridge between app data and AI assistants through familiar agent and plugin concepts.

Why this matters for Power Platform​

Power Platform has always been strongest when it reduces the distance between business logic and end-user experience. What changes here is that the experience is no longer limited to the app canvas or form. Power Apps can now package an action, the metadata that tells Copilot when to invoke it, and an accompanying widget that explains the result in context.
That makes Power Apps more competitive against standalone agent builders because it keeps the workflow close to the system of record. It also lets organizations reuse Dataverse data and app configuration instead of recreating the same logic in a separate bot or external agent platform. That is where the business case becomes more compelling.

The broader Microsoft 365 pattern​

Microsoft has been assembling a broader copilot-and-agents ecosystem for some time, including declarative agents, plugins, connectors, and the Microsoft 365 Agents Toolkit. The Power Apps preview fits that pattern by making app-specific actions available through the same extensibility channels that Microsoft is pushing elsewhere in Microsoft 365.
For enterprises, that means the most interesting question is not whether Copilot can answer a question. It is whether Copilot can safely and reliably help complete a process, using the organization’s own app logic and user interface. That is a much higher bar, and Microsoft is clearly trying to meet it inside the app layer rather than around it.

---

Custom Tools: Turning App Logic into Conversation​

The headline feature in this preview is the ability to create custom tools inside Power Apps and attach them to the app’s MCP server. Microsoft says these tools can be authored directly in Power Apps using a prompt builder designer, and each tool includes a name, description, and instructions that guide the model on what data to produce.
This is more powerful than it may sound. The name and description are not just labels for makers; they are part of the model-routing layer that helps Copilot decide when to invoke the tool. In other words, app makers are now influencing both the business behavior and the AI’s tool-selection behavior through the same low-code workflow.
Because the tools live in the app’s MCP server alongside the built-in Dataverse capabilities, Microsoft is giving makers a single place to define conversational behavior. That simplifies deployment and reduces the need to manage separate orchestrators for app-native actions. It also makes the app more legible to Copilot as a structured agent rather than a simple data source.

From queries to business actions​

The difference between a query and an action is central here. A query asks the model to retrieve or summarize data, but a custom tool can shape that data, enforce business-specific instructions, and prepare it for a downstream UI widget or another tool in the chain. That opens the door to workflows such as escalations, triage, or process reviews that are interactive rather than merely informational.
Microsoft’s own example of a “Sankey Chart Visualizer” captures the point well. A single prompt could initiate a Dataverse query, transform the results into a flow structure, and pass the output to a widget for rendering. That is a far more nuanced interaction than a plain Copilot answer, and it is exactly the sort of thing enterprises have wanted from AI assistants.

The value of metadata​

Tool metadata becomes the steering wheel for the experience. When a tool has a clear purpose, clear instructions, and predictable output, Copilot can route prompts more reliably and chain multiple tools together as needed. That creates a more modular agent design, which is especially useful in large organizations with many distinct business processes.
The practical upside is that makers can create composable business logic without writing a traditional agent stack from scratch. The downside is that the quality of the experience now depends heavily on prompt design, output schema discipline, and maker skill. Low-code does not mean low responsibility.

What this means for enterprises​

For enterprise teams, custom tools could reduce the gap between process documentation and process execution. A tool can encode a standard operating step, expose it in Copilot, and let users trigger it in natural language without leaving the app context. That is likely to be most valuable in service management, sales operations, field workflows, and compliance-heavy reviews.
It also reinforces Dataverse as the underlying system of business meaning. Microsoft explicitly says the built-in tools already handle querying, creating, viewing, and editing Dataverse records, while custom tools extend that logic. So this preview is not a replacement for Dataverse-centric app design; it is an expansion of it.

---

App-Powered UI Widgets​

If custom tools are the brains, widgets are the face. Microsoft describes them as self-contained, MCP-compliant HTML files built on Fluent UI, with automatic support for light and dark Copilot themes. That makes the UI feel native to Copilot while still allowing makers to present richer, domain-specific visuals.
This is a subtle but meaningful design choice. Many enterprise copilots fail because they answer in text while the task actually needs a chart, selector, checklist, or review panel. Widgets let Microsoft move those tasks into a structured, interactive component that can present the right context at the right time.
The new generate-mcp-app-ui skill is also a telling addition. Microsoft is effectively inviting developers to use AI code generation to create the widget layer, which lowers the barrier to producing polished UI while keeping the output aligned with Copilot’s design and host requirements.

Why rich UI matters in Copilot​

Rich UI matters because conversations are not always the best container for decisions. When a user needs to compare cases, inspect trends, or review a process bottleneck, a widget can provide a tighter feedback loop than a text answer ever could. That is especially true when the next step is conditional or requires visual recognition.
It also helps Microsoft avoid a common “chat-only” trap. If every interaction is flattened into text, the experience becomes generic and brittle. Widgets restore the affordances of software: buttons, charts, tables, and structured controls, all inside the conversational flow.

The Fluent UI connection​

By basing widgets on Fluent UI, Microsoft is signaling that the visual layer should feel consistent with the rest of its productivity stack. That consistency matters in enterprise deployments where users move between Teams, Copilot, model-driven apps, and admin portals all day. A familiar visual language reduces cognitive friction and makes the preview more deployable at scale.
The theme-awareness aspect is also important. Copilot surfaces increasingly need to work across dark and light modes, varying host contexts, and different display environments. A widget framework that handles those concerns automatically can save makers a great deal of custom work, provided they respect the host constraints.

Where widgets can go wrong​

The risk is that widgets become too ambitious. The more UI logic a maker pushes into an embedded component, the more testing, accessibility review, and lifecycle discipline the experience will require. That is why Microsoft’s emphasis on MCP compliance and local testing should not be treated as boilerplate; it is a warning about complexity.
There is also a governance issue. Once a widget can present and shape action-ready data inside Copilot, organizations will need to think carefully about which roles can author it, who reviews it, and how changes are controlled. Rich UI is powerful, but in regulated environments it also becomes part of the control surface.

---

How the MCP Server Changes the App Model​

The technical core of this preview is the statement that Power Apps generates an MCP server and a declarative agent from the model-driven app, and that custom tools and widgets plug directly into that agent. That means the app is no longer only a UI plus data model; it is also a conversational endpoint with agent semantics.
This has architectural consequences. Developers no longer need to create a separate service to expose business logic to Copilot if that logic can live in the app’s MCP layer. For many organizations, that simplifies deployment, reduces duplication, and keeps actions closer to the underlying Dataverse schema and permissions model.
Microsoft also makes a point of saying there is no separate infrastructure required. That matters because it lowers the barrier to experimentation and improves the odds that business teams will actually adopt the preview rather than treat it as a lab-only novelty. Lower friction often determines whether a platform feature becomes a pattern.

Declarative agents and app behavior​

The term declarative agent is doing a lot of work here. It implies that the app’s behavior is described rather than coded in a traditional imperative flow, which can make AI orchestration more maintainable in low-code environments. At the same time, declarative systems only work well when the underlying metadata is precise and the intended behavior is unambiguous.
That is why the preview’s emphasis on names, descriptions, instructions, and output testing is sensible. The platform is trying to make the agent understandable to the model before it is trusted in a live business workflow. That is the difference between a demo and a deployable capability.

How this compares with broader Copilot extensibility​

Microsoft’s broader Copilot extensibility documentation already frames agents, connectors, plugins, and APIs as the main ways to extend Microsoft 365 Copilot. Power Apps now joins that family as a business-app-native source of actions and UI, which gives Microsoft a more integrated story for enterprise customers already invested in Dataverse and model-driven apps.
The result is a more coherent stack, but also a more opinionated one. Microsoft is nudging makers toward Microsoft-authored patterns, Microsoft-hosted surfaces, and Microsoft’s governance model. For organizations that value simplicity and vendor alignment, that is attractive. For those pursuing strict platform neutrality, it is a tradeoff.

Sequential setup at a glance​

• Enable the app’s MCP server in Power Apps.
• Create a custom tool with a clear purpose and instructions.
• Optionally generate a widget for the tool’s UI.
• Test the JSON output locally.
• Deploy by updating the app package and publishing it in Teams or the Microsoft 365 admin center.

That workflow is straightforward on paper, but it hides a considerable amount of design judgment. The more carefully makers define outputs and user interactions, the better the resulting Copilot experience will be. Metadata quality is now a product quality issue.

---

Practical Use Cases​

The most compelling applications are the ones where a text answer is not enough. Microsoft’s own examples point toward case progress tracking, process friction analysis, and customer outcome alignment, all of which benefit from visual, contextual presentation. In those scenarios, a widget can show state and trajectory in a way a paragraph cannot.
A service team, for instance, could use a custom tool to summarize unresolved cases and a widget to show where delays cluster. A sales operations team could surface deal-stage bottlenecks. A customer success team could use a tailored action to assess account health and present the results in a compact visual panel.
These are not revolutionary use cases individually. What is new is the packaging: the action, the reasoning, the data access, and the UI all live inside the same Copilot conversation. That reduces context switching and makes the experience feel more like a collaborative workbench than a chat window.

Enterprise vs. consumer relevance​

For consumers, this is mostly invisible. The feature is aimed at IT professionals and model-driven business apps, not broad consumer scenarios. For enterprises, however, it could be one of the more important Power Apps updates of the year because it turns app logic into something users can invoke naturally in the flow of work.
That enterprise focus also explains the prerequisites. Microsoft requires a model-driven app, a Microsoft 365 Copilot license, and permission to upload custom apps in Microsoft Teams. In other words, this is designed for managed environments where deployment, permissions, and oversight already exist.

Where adoption is likely to start​

The earliest adopters will probably be organizations already deep in Dataverse and Power Platform. They are the ones most likely to have structured data, well-defined business processes, and teams that can translate those processes into tools and widgets. They are also the most likely to see immediate ROI from reducing repetitive lookups and manual triage.
A second wave will come from teams that already have internal Copilot initiatives but want to keep the logic inside Microsoft’s governance envelope. For them, the appeal is not novelty; it is consolidation. One app, one agent, one permission model is easier to manage than a sprawl of bots and bespoke integrations.

What makes a good first use case​

Good early use cases will be narrow, repetitive, and data-rich. They should have a clear trigger, a predictable output, and a user decision that benefits from visual context. If the business process is too open-ended, the custom tool layer may become an exercise in prompt archaeology rather than a reliable workflow.
That means many teams should start with review, summary, and triage scenarios before attempting anything that resembles autonomous execution. The preview can certainly support more ambitious designs, but enterprises should treat that as a later phase after the basic operating model has proven itself.

---

Security, Licensing, and Deployment​

Microsoft’s prerequisites are worth reading carefully because they define the real boundary of the preview. The feature requires a model-driven app, a Microsoft 365 Copilot license, and permission to upload custom apps in Microsoft Teams. Microsoft also notes that the feature is available only for model-driven apps at this time and starts with early release stations.
The deployment path is intentionally familiar. Makers can download the updated app package and publish it to Teams or through the Microsoft 365 admin center. That suggests Microsoft wants organizations to treat these experiences as governed enterprise assets, not local experiments.
There is also a licensing and capacity angle already visible in the broader Copilot documentation. Microsoft says model-driven app Copilot depends on Dataverse Search indexes, can increase capacity consumption, and requires both Power Apps premium and Microsoft 365 Copilot licenses in some scenarios. That makes budget planning an important part of the rollout conversation.

Governance matters more in preview​

Preview features are inherently moving targets, but Microsoft’s own documentation and rollout notes show that access may vary by region and that some settings may not yet be visible everywhere. That means administrators should expect uneven availability and prepare for iterative policy updates.
The governance issue is not just about access. Once custom tools can trigger business actions, organizations need to define approval rules, logging expectations, and test criteria for the prompt builder content and widget outputs. Anything less than disciplined change control risks turning a productivity feature into a shadow automation layer.

Security boundaries and trust​

The fact that widgets are MCP-compliant HTML files is both useful and important. It gives Microsoft a structured trust model, but it also means organizations should treat widget content as code, not decoration. Code generation can accelerate delivery, yet it can also amplify mistakes if the review process is weak.
Because the experience is embedded in Copilot, security teams will also need to think about what information the widget exposes and how it behaves in different user roles. When an action is surfaced in a conversational interface, the UX can disguise the underlying permissions model unless the implementation is careful.

Deployment tradeoffs​

Teams is a pragmatic deployment target because many organizations already use it as the work hub. The Microsoft 365 admin center path also keeps the experience inside familiar admin tooling. That said, the more distributed the rollout, the more important consistent packaging and version control become.
The preview’s simplicity is a strength, but it should not be confused with minimal operational overhead. Once a custom tool is used by a business unit, the team owning it inherits testing, support, and governance obligations. The fact that it is “low-code” does not remove the need for lifecycle management.

---

Competitive Implications​

This preview also matters in the broader AI platform race. Microsoft is trying to make Copilot not merely a chat product, but a distribution layer for business actions across its own application ecosystem. That puts pressure on competitors that offer generic copilots without deep ties to systems of record.
For low-code and enterprise workflow rivals, the message is clear: Microsoft wants to own the conversational front end and the business app back end at the same time. If Power Apps can expose rich, app-specific actions inside Copilot with little extra infrastructure, then the value proposition of building a separate assistant weakens.
It also tightens Microsoft’s ecosystem lock-in in a way customers may either welcome or resist. The integration of Dataverse, Power Apps, Teams, Microsoft 365 Copilot, and MCP creates a very cohesive experience. But that coherence can make it harder to substitute third-party components later without reworking the conversational layer.

Why rivals should pay attention​

Rivals should pay attention because Microsoft is not stopping at “chat with data.” It is pushing toward chat with action, where the conversation itself becomes the interface for business operations. That is a materially stronger platform story and one that is likely to resonate with enterprises seeking efficiency.
There is a second-order effect too: once users become accustomed to richer Copilot interactions, plain-text assistant experiences may feel underpowered. Visual context, actionability, and workflow integration can become baseline expectations rather than differentiators. That is how platform shifts happen quietly.

---

Strengths and Opportunities​

This preview has several clear strengths. It builds on existing Power Apps investments, adds a richer interaction model, and keeps everything inside Microsoft’s enterprise governance and identity framework. That combination should make it easier for organizations already using Dataverse and Microsoft 365 Copilot to experiment without rebuilding their stack.

• Brings custom business actions into Copilot without separate infrastructure.
• Keeps app logic close to Dataverse and existing Power Apps investments.
• Adds widgets for visual, contextual, action-ready experiences.
• Uses Fluent UI and theme adaptation for a more native Copilot feel.
• Supports low-code authoring through the prompt builder designer.
• Enables tool chaining for multi-step interactions from one prompt.
• Fits naturally into Microsoft 365 admin and Teams deployment paths.

The opportunity is especially strong in process-heavy industries. Customer service, healthcare administration, financial operations, logistics, and internal IT service management all benefit from guided actions and structured data presentation. If Microsoft can keep the experience simple enough for makers and trustworthy enough for administrators, adoption could accelerate quickly.

---

Risks and Concerns​

The risks are equally real. Preview features can change, and Microsoft’s own notes make clear that this one is limited to model-driven apps, early release stations, and specific licensing and permission conditions. That will constrain adoption at first and may frustrate teams expecting broader reach.

• Preview status means APIs, behavior, and availability may shift.
• Limited to model-driven apps, so canvas-app users are out for now.
• Requires Microsoft 365 Copilot licensing and admin permissions.
• Could increase governance complexity for custom tool creation.
• Widget generation adds a code-review burden even in low-code contexts.
• Dataverse Search and capacity planning may become more important.
• Overly broad tools could produce confusing or unreliable Copilot routing.

There is also a user-experience risk. If makers over-automate or over-pack a widget, the Copilot experience can become cluttered and difficult to trust. The promise of “less like requests and more like collaboration” will only hold if the app stays readable, predictable, and aligned with real business steps. That balance is harder than it looks.

---

Looking Ahead​

The next milestone to watch is whether Microsoft expands this beyond model-driven apps and early release stations. If the company brings the same concept to more app types and more regions, the feature could become a foundational part of Power Apps’ Copilot story rather than a niche preview.
A second question is whether Microsoft deepens the tooling around quality, testing, and governance. The more the platform relies on prompt metadata and generated widgets, the more customers will want guardrails, diagnostics, and lifecycle controls that go beyond a basic builder experience. That will be the difference between a flashy preview and an enterprise standard.

What to watch​

• Broader availability beyond early release stations.
• Possible support for additional app types.
• Better governance and auditing for custom tools.
• More templates for common business scenarios.
• Stronger widget validation and accessibility guidance.
• Deeper integration with Microsoft 365 Copilot extensibility.

The most interesting strategic question is whether Microsoft can make these experiences feel natural enough that business users stop thinking about tools and start thinking about outcomes. If it can, Power Apps will have moved from app builder to conversational operating layer, and that is a much bigger story than a single preview announcement.
Microsoft’s public preview is therefore less about flashy AI and more about operational design. It brings app logic, UI, and Copilot into one governed surface, which is precisely where enterprise software is heading. The companies that learn to shape that surface now will be in the strongest position when these previews harden into everyday workflow infrastructure.

---

Source: Microsoft Custom tools and rich UI for app-based conversations are now in Public Preview - Microsoft Power Platform Blog