Your Copilot, Your Rules: Customizing Chat For Model-Driven Apps

Something fundamental is changing in how Power Apps and Microsoft 365 Copilot work together. Until now, Copilot in Model-Driven Apps lived in its own world—a helpful chatbot embedded in your app, but isolated from the rest of M365. Meanwhile, M365 Copilot was transforming how people work in Word, Excel, Teams, and Outlook, but it knew nothing about your Power Apps.

That gap is closing.

Microsoft is converging these two experiences through Apps in Copilot (Public Preview). Your Model-Driven Apps can now become intelligent agents accessible directly from M365 Copilot—not as external links, but as first-class conversational experiences. Users can interact with your app’s data through interactive grids and forms without ever leaving their M365 workflow. But here’s where it gets interesting: you’re not limited to grids and forms. With Custom Tools and Widgets, you can define your own business logic, create custom visualizations (charts, maps, dashboards, timelines), and deliver interactive UI components built with HTML and Fluent UI. Your app becomes more than a data source—it becomes an intelligent agent with tailored experiences that surface exactly the way you need them to. This isn’t just an integration. It’s a new architecture: your app as an agent in AI conversations.

In this article, you’ll learn:

• The evolution of Copilot in Model-Driven Apps and why we’re at a turning point
• What the old Copilot Chat could do (and why it’s being deprecated)
• How to transform your Model-Driven Apps into M365 Copilot agents
• What grids and forms give you automatically (and their limitations)
• How to build Custom Tools with interactive widgets for advanced scenarios
• How to unbundle business intelligence with Business Skills

The Evolution of Copilot in Model-Driven Apps

When Copilot Chat arrived in Model-Driven Apps in 2024, it was revolutionary. Users could ask questions in natural language instead of navigating complex filters. But there was a fundamental limitation: it was read-only by default. You could extend it through Power Automate orchestration, but the core experience didn’t honor your existing client-side customizations—plugins, JavaScript logic. Either you lived with a limited experience, or you rebuilt logic server-side just to make Copilot work properly. By late 2024-2025, Microsoft’s vision crystallized: “Copilot is the UI for AI” (Microsoft Ignite 2024). This meant converging all intelligence layers—Copilot, Copilot Studio, Agents—into a unified architecture. For Power Apps, this meant a fundamental shift: your app couldn’t stay isolated inside Copilot Chat anymore. In 2025-2026, Apps in Copilot delivered on that vision. Your Model-Driven Apps became agents accessible from anywhere in M365. Your business logic can now live in Business Skills that any agent could discover. Your custom actions or UI could appear as Custom Tools. The shift was complete: from “AI as a chatbot in your app” to “your app as an intelligent agent in M365 conversations.“

Understanding the Transition

The shift from old Copilot Chat to Apps in Copilot isn’t just a feature refresh—it’s a response to real problems that emerged as organizations tried to make the 2024-2025 customization era work.

What We Could Do (The Old Magic)

By 2024-2025, we had built powerful capabilities to extend the Copilot in experiences. Topics brought true process automation into conversations. You wrote workflows in Power Automate, exposed them to Copilot, and the chatbot could execute multi-step business processes. With record pickers and variables, Copilot understood the context it was working in—which account, which case, which opportunity. Your processes could actually do things now, not just answer questions. Sparkle Menus organized Copilot suggestions into business-relevant categories. Instead of showing every possible action, users saw only what mattered for their current context. It felt intelligent because it was. Knowledge Sources made Copilot smarter about your business. Feed it company policies, SOPs, customer information, pricing rules—and the assistant would cite these sources when giving advice. It stopped hallucinating and started being actually useful for domain-specific questions. These weren’t minor improvements. They fundamentally changed what Copilot Chat could accomplish. Organizations built real value on top of them. But they were still operating within a constraint.

For more details you can have a look about one of my previous article: Extending Copilot in Dynamics 365 Sales with Copilot Studio — Tailor It Your Way – Allan Insights

Why We Had to Evolve (The Breaking Point)

The first step Microsoft took was bringing M365 Copilot INTO your Model-Driven Apps. Instead of the old isolated Copilot Chat, your MDA could now use M365 Copilot as its in-app chat experience. Dataverse started indexing your app’s data, so users could query it from the M365 Copilot experience inside the app.

This was a real improvement—M365 Copilot and your apps were finally getting closer. But it still wasn’t enough. Here’s what was still broken: Your app’s intelligence was trapped. Even with M365 Copilot integrated in the MDA, all that logic only existed inside your Model-Driven App. Users working in Word, Excel, Teams, or Outlook couldn’t access it. They still had to switch contexts, jump into the app, and come back. The friction remained. Your app couldn’t act as an agent elsewhere. M365 Copilot across the rest of M365 could access your emails, documents, and conversations—but it had zero knowledge of your Power Apps as standalone agents. You had intelligence locked inside the MDA, inaccessible from where users actually worked. Logic duplication was still the only way. If you needed the same workflow in both your MDA and the broader M365 Copilot, you built and maintained it twice.

The real breakthrough needed wasn’t just bringing M365 Copilot into your app. It was bringing your APP into M365 Copilot. That’s what Apps in Copilot delivers.

The New Vision

Apps in Copilot solves this by fundamentally changing the relationship between your Power Apps and M365 Copilot. Instead of your app having its own Copilot experience, your app becomes an agent that M365 Copilot can use. Your business logic isn’t duplicated—it’s stored once in Dataverse and accessed by any agent. Your custom tools aren’t hidden inside your app—they’re discoverable and invocable from anywhere in M365. It’s not “Copilot in my app anymore.” It’s “my app in Copilot.”

This single shift solves the architectural problems of the previous era:

• Intelligence is centralized, not scattered across multiple interfaces
• Users access your app’s logic from wherever they’re already working
• Business logic is defined once and reused everywhere
• The migration path is clear: move away from old Copilot Chat, toward the unified M365 Copilot + Apps in Copilot architecture

Apps in Copilot – The Transformation

This is where the architecture actually changes. Apps in Copilot isn’t just a new feature—it’s a fundamentally different way to think about how your Model-Driven Apps deliver value.

From App to Agent

Your Model-Driven App becomes an agent accessible directly from M365 Copilot. Not as an external link. Not as an embedded chatbot. As a first-class agent that lives in the same conversational experience your users already use for everything else in M365.

Here’s what that means in practice:

A user is writing a report in Word. They add their MDA agent and ask M365 Copilot: “Show me all high-priority accounts in the West region.” Copilot queries your app, surfaces results as an interactive grid right there in Word, and the user can click to view details, update records, or deep link to the full app without leaving their workflow.

A support agent is working in Teams. They add their MDA agent and ask Copilot: “Create a new case for this customer with these details.” Copilot invokes your app’s create action, renders an interactive form inline, collects the information, and submits it—all in the chat conversation.

A sales rep is in Outlook reviewing emails. They mention their MDA agent and ask Copilot: “What opportunities are at risk in my territory?” Copilot queries your app and surfaces a custom visualization—maybe a risk heat map, maybe a timeline—built with your custom tools. Your app isn’t hidden anymore. It’s everywhere your users already work.

Your app isn’t hidden anymore. It’s everywhere your users already work.

Setup Process (One-Time)

The setup is surprisingly simple because Microsoft handles most of the complexity:

• Power Apps → Your Model-Driven App → Left Pane→ App MCP (preview)
• Enable the App MCP (preview)
• Download the app package (this contains your declarative agent + MCP server)
• Upload to Teams or Microsoft 365 Agents Users can immediately start interacting

That’s it. You’re not building an agent from scratch. You’re not writing custom integrations. Microsoft generates the MCP server and declarative agent from your app’s schema automatically.

What you get automatically:

• Interactive Grids: Users can browse, filter, sort your app’s data
• Smart Forms: Create, view, edit records inline without leaving Copilot
• Built-in tools: Copilot understands your app’s queries and actions
• Deep links: Users can jump to the full app when they need advanced features

The one-time setup means you deploy once, and it works across all M365 surfaces: Word, Excel, Teams, PowerPoint, Outlook, M365 Copilot.

Current Limitations

This is where theory meets practice. Based on hands-on testing during the Preview, here’s some example of things that doesn’t work.

Form headers don’t render in the Copilot experience. If your form header is a critical piece of information, you need to move that content into the form body itself. The command bar isn’t available—so custom actions that live in the command bar won’t show up. If you have multiple forms for the same table, users can’t select which form they want. You’ll need to handle that through custom tools. Subgrid support is awesome and you can act on column but there’s no text search capability or group by, the default view isn’t always honored, and users can’t switch views at runtime. If you need advanced subgrid interactions, plan to deep link to the full app. Field type support has gaps. File columns aren’t supported. Formula columns and calculated fields have limited rendering etc.. Multi-environment setups have identification challenges—knowing which environment an agent package came from. The developer name in the manifest doesn’t always update, causing conflicts across environments. These aren’t deal-breakers. They’re constraints you need to design around. The feature is in Public Preview (May 2026), so Microsoft is actively working on it, so this is not a big stop for us.

Pro Tips & Best Practices

Setup & Deployment: Use Early Release environments for testing feature if you want to have a look on what’s coming up. Re-download your app package after metadata change to your apps —tables, forms, views. When naming agents, follow a convention like `[AppName] – [Environment]` so users know which version they’re working with. Test package deployment in DEV first. Don’t assume it’ll work in SIT or UAT if you haven’t validated it .

Multi-Environment: Maintain separate packages for DEV, SIT, UAT, and PROD. Don’t try to reuse the same package across environments as they’re targeting a specific environment and use the MCP bound to the target environment. Update the manifest developer name for each environment—this prevents versioning conflicts. Document your package versions in release notes so you know which version is deployed where.

Debugging: When something breaks, type `-developer on` in M365 Copilot before reproducing the issue. This shows you the Agent ID, Conversation ID, Request ID, and which tools were invoked. This information is essential for bug reproduction and reporting to Microsoft. Save those IDs before you close the conversation.

Form Design: Move header fields to the form body if they’re important. Design forms assuming the command bar won’t be available. Avoid file columns, formula columns, and rollup fields in chat-optimized forms. Keep forms compact—single tab focus is best.

Custom Tools & Widgets (Preview)

Here’s where Apps in Copilot becomes truly powerful: you’re not limited to grids and forms. You can build custom tools with interactive widgets tailored to your specific business needs.

Why Go Custom ?

Sometimes grids and forms aren’t enough. You need specific business logic: “Show my opportunities pipeline as a bubble chart” or “Show me 360 degree view about a specific account”. You need custom visualizations: charts, maps, dashboards, timelines that aren’t standard table views. You need tailored experiences: your data presented your way. Custom tools let you do all of that.

Custom Tool Anatomy:

A custom tool has four components:

• Name & Description: Copilot uses this metadata to discover and decide when to invoke the tool. Good descriptions matter—they tell the AI when and why to use your tool.
• Instructions: The query logic and parameters. “When called with account ID and date range, query the Opportunities table with these filters, calculate risk scores based on these rules, and return results sorted by risk level.”
• Output Format: JSON or plain text. If it’s JSON, you can structure it for parsing. If it’s text, Copilot will work with whatever you return.
• Custom Widget (Optional): HTML + Fluent UI that renders the output as an interactive visualization. This is where the magic happens—your JSON data becomes a beautiful, interactive UI right in Copilot.

The /generate-mcp-app-ui Skill:

Writing HTML widgets from scratch is tedious. Microsoft provides an AI-powered skill called “/generate-mcp-app-ui” available in Claude Code and GitHub Copilot CLI:

1. Describe what you want the visualization to look like
2. Paste into /generate-mcp-app-ui with your description
3. AI generates HTML + Fluent UI code
4. Copy the HTML into your custom tool widget
5. Test and iterate

This workflow cuts widget development time dramatically. The AI understands your data structure and generates components that match your Copilot theme automatically.

Examples: Account 360 View & Pipeline Overview

Example: Get Account 360

My goal with this custom tool was straightforward: show that you can build a custom UI rendering that gives users a 360-degree view of an account in one glance. I started to create the tool as following:

Tool Name: Get Account 360

Tool Description: Get a 360-degree view of a single account by name: company details, key stats, and the contacts linked to that account. Use when the user asks about a specific company, customer, or account by name.

To ensure that this tool is doing what I do expect him to do I provided clear instruction to it including fields that must be used to get the data, a guardrail to explicitly indicates when to use and when to not use this tool and a specific JSON Format.

Based on my JSON structure I leverage the skills provided by Microsoft to generate the HTML Widget (you can access it only by first testing your tool instruction by clicking on Update Tool).

How it works:

• User asks in M365 Copilot: “Tell me about Microsoft”
• Copilot recognizes this is an account lookup and invokes the “Get Account 360” tool with parameter: `name=”Microsoft”`
• The tool queries Dataverse: filters the Account table by name and retrieves all related Contacts
• Returns structured JSON containing:
  • Account details: name, type (customertypecode), revenue, currency, phone, email, address –
  • Linked contacts: fullname, jobtitle, email for each contact
• The Account 360 widget receives this JSON and renders it as an interactive dashboard

Let’s see it in action:

Another Example: Get Pipeline Overview

Here’s another custom tool I built using the same approach: Get Pipeline Overview. Instead of account information, it returns a sales rep’s open opportunities: deal name, account, value, probability, stage, and expected close date. Copilot filters results based on natural language constraints (“show me only Commit-stage deals over €100k” or “what’s closing this month”). The custom widget renders this as an interactive bubble chart—a visual representation of the pipeline that lets reps see their forecast at a glance, identify which deals to focus on, and drill into details without leaving Copilot.

Business Skills – Teaching Agents Your Organization

Your business logic doesn’t need to be trapped in code or buried in documentation. Business Skills let you capture how your organization actually works—your processes, policies, domain knowledge—in natural language that agents can discover and follow at runtime.

The Unbundling Challenge

Here’s the problem: your business intelligence is scattered. Critical processes live in your plugins. Policies live in SharePoint documents nobody reads. Domain expertise lives in the heads of your senior team members etc.. When you ask an agent to perform a task, the agent has no knowledge of how your organization actually works. It makes generic decisions based on generic logic or based on agent flows & topics etc.

The Question about how do you unbundle organizational intelligence so agents can discover and follow it? is now possible to address with Business Skills.

What Are Business Skills?

Business Skills are natural-language instructions stored in Dataverse that describe how to complete a specific type of work. They’re not code. They’re not workflows. They’re natural language that guides agent behavior. When an agent needs to complete a task, it queries all available Business Skills (through the Dataverse MCP Server, if not used then Business Skills will not be discovered), finds the one that matches the user’s request, retrieves the full instructions, and follows them step by step.

A Business Skill has the same basic structure you can use in any agent today: a name, description, and step-by-step instructions in plain language/markdown. You can also attach resources like policy documents, templates, or images. You define visibility (individual or organization-wide) to control who can discover and use the skill. Everything is solution-aware and packageable for ALM—except the resource files, which are just attachments.

Why This Matters:

• Reusability: Define a process once. Use it across all agents (Copilot Studio, GitHub Copilot, VS Code, Azure AI Foundry, any MCP client).
• Consistency: Multiple agents using the same skill means the same process everywhere. No variation. No surprises.
• Maintainability: Update the skill in Dataverse. The change applies everywhere immediately. No need to find and patch individual agent configurations.
• Governance: Skills are solution-aware objects in Dataverse. They follow RBAC. You control who can create, edit, and use them.

Wrapping Up

Business Skills represent a fundamental shift in how we express organizational logic. Instead of hard-coding processes in plugins, JavaScript, or Power Automate flows, we formalize them as declarative text that agents can discover, understand, and follow. Will it become the standard way we work? I don’t know yet. But I love the idea: moving from code-based logic to natural-language processes. That’s a real change in how we think about what’s automatable and what’s repeatable.

Conclusion

The journey from isolated Copilot Chat to M365 Copilot integrated in your MDA, and now to Apps in Copilot, represents a fundamental shift in how your Model-Driven Apps deliver value. Your apps are no longer confined to their own interface. They become intelligent agents accessible from anywhere in M365. Your business logic moves from plugins and flows into discoverable, natural-language Business Skills that agents can understand and follow (thanks to Dataverse MCP Server). It’s a real architectural change in how we think about automation and intelligence in business applications. Now it’s your turn to build.

The post Your Copilot, Your Rules: Customizing Chat For Model-Driven Apps appeared first on Allan Insights.

Original Post https://www.blog.allandecastro.com/your-copilot-your-rules-customizing-chat-for-model-driven-apps/