Canvas apps have always been known for rapid development using a low-code, drag-and-drop approach. However, even with this speed, developers still spend a significant amount of time on repetitive UI building, writing Power Fx formulas, and refining logic manually.

Microsoft has recently introduced support for external AI-powered development tools for Canvas Apps. This allows developers and business users to work with AI-assisted tooling outside the traditional Power Apps Studio experience. Using external tools such as GitHub Copilot, AI agents, and Power Platform skills, users can now generate Canvas App structures, layouts, and workflows using natural language prompts.

This blog explores the setup experience, the architectural shift introduced by these tools, and most importantly how AI-assisted Canvas App generation can significantly accelerate development and provide a strong starting point for projects.

Key Takeaways

• Generate Canvas Apps using natural language prompts with external AI-powered tools.
• AI agents can automatically create screens, navigation, and basic app logic.
• Reduce manual setup and accelerate development with GitHub Copilot and Power Platform skills.
• Sync generated changes directly to live Canvas Apps through coauthoring.
• Ideal for rapid prototyping and app scaffolding, while complex logic still requires developer expertise.

Overview

The introduction of external AI tooling for Canvas Apps represents a major change in the Power Platform ecosystem. Instead of relying completely on drag-and-drop development inside the browser, users can now interact with AI agents capable of understanding application requirements and generating app structures automatically.

The workflow combines:

• GitHub Copilot and AI-assisted coding tools
• Power Platform skills and AI agents
• Local CLI-based tooling
• Canvas App source generation
• Natural language prompts

This creates a development experience that feels closer to modern software engineering workflows rather than traditional low-code configuration.

One of the most interesting aspects of this approach is that the AI system is no longer behaving like a simple chatbot. Instead, it works through

specialized agents such as:

• canvas-app-planner
• canvas-screen-builder

These agents understand specific Power Platform concepts and can generate app scaffolding, screen layouts, navigation structures, and other components based on user instructions.

Prerequisites and Setup

Before working with external AI tools for Canvas Apps, several prerequisites must be configured locally.

Required Tools

The following components are required:

• .NET SDK 10+
• GitHub CLI
• Git installation
• Power Platform CLI
• GitHub Copilot access
• Power Apps environment access

These tools provide the local runtime, authentication, AI integration, and Power Platform connectivity required for AI-assisted Canvas App generation.

You also need to have Environment ID and Canvas App ID (if you need to modify in an existing app).

Installing the Power Platform Skills Plugin

To enable Canvas App generation capabilities, the Power Platform Skills marketplace plugin must be installed.

The following commands can be executed using either:

• Copilot CLI
• Claude Code

Step 1 – Add the Power Platform Skills Marketplace

/plugin marketplace add microsoft/power-platform-skills

Step 2 – Install the Canvas Apps Plugin

/plugin install canvas-apps@power-platform-skills

After installation, restart the CLI session to load the newly added skills:

/restart

Once restarted, the environment exposes specialized AI agents and skills capable of assisting with Canvas App generation and screen creation.

Enabling Coauthoring for Canvas Apps

To use AI-assisted capabilities with Canvas Apps, coauthoring must be enabled for the application.

This can be configured inside Power Apps Studio:

Power Apps Studio

→ Settings

→ Updates

→ Enable Coauthoring

Without coauthoring enabled, the AI tooling cannot properly interact with the Canvas App source.

Connecting to the Power Platform Environment

Before generating apps, authentication with the target Power Platform environment is required.

Run the following command:

pac auth create –environment <your_environment_url>

This establishes the connection between the AI tooling and the Power Platform environment.

The environment ID is also required so the AI agents can correctly identify the target instance during app generation.

Initializing the Canvas App AI Workflow

Once the setup is complete, the Canvas App workflow can be initialized using:

/canvas-apps:canvas-app

This configures the MCP server connection and prepares the environment for AI-assisted Canvas App creation.

After initialization, users can begin generating app structures, screens, and workflows using natural language prompts.

Implementation

Instead of starting with a blank canvas and designing every screen from scratch, you can now just describe what you want in plain English. Something like:

“Create a LeadBoard showing all leads in card format. Clicking a card should open a qualification form where I can enter a score and add notes, with an option to save.”

That is all it takes to get started.

After you submit the prompt, the AI agent gets to work. It reads your requirement, checks the necessary connections, and starts building the app for you. One thing I really liked about this experience is that you can actually watch it work in real time, you are not just staring at a loading screen waiting for something to appear.

What surprised me is that the agent does not just guess and generate. If your prompt is missing something, it asks. It might check whether you have a preferred layout in mind, whether the data is already set up, or how many screens you need.

This means even a rough prompt gets you a decent result. The agent fills in the blanks by asking the right questions, so you are not stuck fixing a broken app just because you forgot to mention something upfront. The experience feels less like using a conventional tool and more like interacting with a partner that understands your objectives and provides meaningful assistance beyond basic commands.

Once everything is confirmed, it generates the screens, sets up the navigation, connects the data source, and puts together the basic app logic. Within a few minutes you have something you can actually open and use, not just a wireframe or a demo.

The results were better than I expected. Once the files were ready, the CLI compiled them and pushed the changes directly into the live app through coauthoring – the LeadBoard appeared in Power Apps Studio in real time without any manual copying or pasting. The card layout came through cleanly, showing each lead’s name, company, and source.

During the generation process, the AI asked whether a search bar should be included. We confirmed yes, and it handled the rest. It is a small thing but it reflects how the agent approaches requirements, it does not assume, it asks, and then it delivers exactly what was agreed.

The qualification screen came through the same way, compiled and synced live. A form with a score input, a notes field, and a Save button that writes back to the Lead record in Dataverse.

This is where AI-assisted Canvas App development really shows its value. Business users can take an idea and turn it into a working app quickly, without needing a developer involved from day one.

That said, there is a limit to what the AI handles well. If your app needs complex business logic, external integrations, security controls, or needs to scale across an enterprise, you will still need a developer in the loop. But the AI gives you a solid starting point. The boring setup work, scaffolding screens, wiring up navigation, connecting data, is done for you. Developers can jump straight into the parts that actually need their expertise.

Wrapping Up

The biggest takeaway from this experience is not that AI can generate a Canvas App for you. It is that it gives you a real starting point you can actually work from.

When I started this, I expected the AI to handle most of the heavy lifting. What I got instead was a collaboration, I described what I wanted, the agent generated a foundation, and then the real work began. Fixing YAML schema errors, figuring out the right control types, getting the Gallery variant string correct, iterating on the card design, none of that was automatic. But I was doing it on top of something that already existed, which is fundamentally different from staring at a blank canvas.

For business users, this matter because they can now describe an idea in plain English and get something tangible back within minutes. They do not need a developer just to see what an app might look like.

For developers, the value is different. The scaffolding, screens, navigation, basic data connections, is handled. You come in for the parts that actually need your skills: the business logic, the integrations, the performance tuning, the governance. The repetitive setup work that used to eat the first day of any project is largely gone.

That said, AI tooling for Canvas Apps is still maturing. The YAML schema is strict, control type strings are version-specific, and the gap between what the agent generates and what Studio actually accepts requires hands-on debugging. Knowing the platform well is still a prerequisite for getting the most out of these tools, not a nice to have.

Canvas App development is moving toward an AI-assisted engineering workflow. We are not there yet, but projects like this make it clear the direction is set.

The post AI-Assisted Canvas App Development Using External Tools in Power Apps first appeared on Microsoft Dynamics 365 CRM Tips and Tricks.

Organizations today store massive volumes of structured data sales figures, inventory records, and financial reports in Excel and CSV files across SharePoint libraries. When someone needs a quick insight from that data, the typical path involves downloading the file, opening it in Excel or Power BI, writing formulas or building visuals, and then sharing the result. It works, but it’s slow, manual, and requires a level of technical skill that not every team member has.

What if there was a way to simply ask a question and get the answer complete with accurate calculations and even a chart without ever leaving a chat window.

That’s the promise of Code Interpreter in Microsoft Copilot Studio. This preview feature allows Copilot Studio agents to go beyond simple Q&A by dynamically generating and executing Python code to analyze structured data files. When paired with a SharePoint Document Library as a knowledge source, it creates a powerful self-service analytics experience: users ask questions in plain English and the agent does the heavy lifting searching SharePoint for the right file, writing the code, running the computation, and delivering the result.

In this blog, we’ll explore what Code Interpreter is, how it works with SharePoint, and see it in action.

Code Interpreter is a capability within Microsoft Copilot Studio that enables AI agents to generate and execute Python code on the fly in response to user queries. Rather than relying solely on the large language model’s inherent reasoning which can be unreliable for math and data-heavy questions Code Interpreter offloads analytical tasks to deterministic Python computations.

The agent doesn’t estimate the answer. Instead, it writes a precise Python script, runs it against the actual data, and returns the calculated result. The math is real. The answer is accurate. And the user never sees a single line of code unless they choose to.

You can enable code interpret in the agent setting in Generative AI, scrolling down you will find the option for code interpreter and enable that.

There are two ways to feed structured data into a Copilot Studio agent for analysis. The first is user-uploaded files where someone attaches a CSV or Excel file directly in the chat. The second, and more enterprise-relevant approach, is connecting a SharePoint Document Library as a knowledge source. In this blog, we focus on the SharePoint approach.

When a user asks an analytical question, the agent follows a multi-step process behind the scenes:

1. Understand the query: The orchestrator interprets the natural language question and determines it requires data analysis.
2. Search SharePoint: The agent uses Work IQ Microsoft’s enhanced retrieval layer to search the connected SharePoint knowledge source and locate the relevant structured file.
3. Retrieve and inspect: The agent retrieves the file content and examines its structure columns, data types, and rows.
4. Generate Python code. Based on the query and the data, the agent writes a Python script tailored to answer the question.
5. Return the result. The output a table, a chart, a number, or a summary is delivered back to the user in the chat.

To demonstrate this capability, we have two structured datasets stored in a SharePoint Document Library SalesReport.xlsx containing employee-level sales performance data, and BusinessSalesAnalysis.xlsx containing order-level business data with products, categories, regions, and revenue.

With Code Interpreter enabled and the SharePoint files connected as a knowledge source, the agent can now answer analytical questions directly. Let’s see how it responds to a couple of queries.

Below are some of the question asked to the agent.

Query 1: “Which product category generated the highest revenue in the uploaded Excel report?”

The agent identified the relevant file, executed Python code to calculate revenue by product category, and returned a clear breakdown Electronics leading at $738,000 followed by Furniture at $517,000. It even highlighted key revenue drivers like Laptops and Monitors.

Query 2:  Analyze the uploaded sales dataset and provide a summary of overall business performance.

This time, the agent analyzed both datasets together and returned a comprehensive summary $1,255,000 in total revenue, $286,000 in profit, 321 units sold, and a 22.79% profit margin. It also generated a month-over-month revenue and profit trend table from January through May.

As you can see, the agent has used the Code Interpreter to answer the user’s queries generating Python code behind the scenes, running real calculations against the SharePoint data, and returning accurate, formatted results directly in the conversation. No manual data work. No formulas. Just a natural language question and a precise answer.

Conclusion

Code Interpreter in Microsoft Copilot Studio brings real computational power to the conversational AI experience. By combining natural language understanding with deterministic Python execution and grounding it in the structured files already living in SharePoint it creates a genuinely useful self-service analytics layer. Users ask questions in plain language. The agent finds the data, writes the code, runs the computation, and delivers the answer all within seconds.

FAQs

What is Code Interpreter in Microsoft Copilot Studio?

Code Interpreter is a capability in Microsoft Copilot Studio that enables AI agents to generate and execute Python code automatically. It allows agents to perform data analysis, calculations, visualizations, and file processing based on user queries, delivering accurate results directly within a conversation.

How does Code Interpreter work with SharePoint files?

When SharePoint Document Libraries are connected as a knowledge source, the Copilot Studio agent can locate relevant Excel or CSV files, analyze their contents, generate Python code to answer user questions, execute the code, and return insights such as summaries, calculations, tables, or charts.

Can Microsoft Copilot Studio analyze Excel files stored in SharePoint?

Yes. Microsoft Copilot Studio can analyze Excel files stored in SharePoint when the library is configured as a knowledge source and Code Interpreter is enabled. Users can ask questions in natural language, and the agent retrieves and analyzes the data automatically.

What types of files can Code Interpreter analyze?

Code Interpreter primarily supports structured data files such as Excel (.xlsx) and CSV (.csv) files. These files can be uploaded directly by users or accessed through connected SharePoint Document Libraries.

Why is Code Interpreter more accurate for data analysis?

Unlike traditional AI responses that rely on probabilistic reasoning, Code Interpreter generates and executes actual Python code against the source data. This ensures calculations, aggregations, and analytical results are based on real data processing rather than estimation.

The post Streamlining SharePoint File Analysis with Microsoft Copilot Studio Code Interpreter first appeared on Microsoft Dynamics 365 CRM Tips and Tricks.

Artificial Intelligence is rapidly becoming the backbone of modern web experiences. Microsoft Power Pages has embraced this shift by weaving AI-powered features deeply into both the site-building and the end-user journey from intelligent chatbots and smart search summaries to AI-assisted form filling and data summarization.

But with great power comes the need for great governance. How do administrators ensure that these AI features are used responsibly across multiple environments? How do they track which features are being adopted, and by how many users? Enter the Copilot Hub for Power Pages, a centralized command center inside the Power Platform Admin Center designed to give admins full visibility and control over AI capabilities.

In this blog, we will walk through the Copilot Hub in detail, what it offers, why it matters, real-world use cases, and a step-by-step guide for admins to get started.

NOTE: This feature is currently in Preview and is being gradually rolled out across regions. Ensure your Power Pages site runs on runtime version 9.7.4.xx or later before using the Copilot Hub.

Key Takeaways

• Gain centralized visibility into AI feature adoption across all Power Pages environments.
• Monitor both maker and end-user Copilot usage through built-in analytics and insights.
• Control AI-powered capabilities at the environment or site level with granular governance settings.
• Support compliance and security requirements by selectively enabling or restricting AI features.
• Provide a seamless experience for users through automatic fallback to standard functionality when AI features are disabled.

What is the Copilot Hub for Power Pages?

The Copilot Hub is a dedicated section within the Power Platform Admin Center that provides a unified dashboard for tenant administrators to monitor, analyse, and govern the usage of AI-powered features across all Power Pages environments in their tenant.

In simple terms, it answers three critical admin questions:

• Who is using AI features, and how often?
• Which AI features are enabled or disabled across my environments?
• How do I control AI feature access for makers and end users at a granular level?

The Copilot Hub is split into two primary capabilities:

• Analytics & Insights
• Governance Controls for AI Features

 Real- World Use Cases

Before diving into the how-to, let us look at scenarios where the Copilot Hub solves real business problems.

Use Case 1: Financial Services – Compliance-Driven AI Governance

A bank uses Power Pages for a loan application portal. Due to compliance regulations, they cannot allow AI to auto-fill sensitive form fields on certain forms. The admin uses the Copilot Hub’s granular site-level controls to disable AI Form Fill Assistance on specific loan application sites, while keeping it enabled on informational sites. This gives them the compliance control they need without disabling AI globally.

Use Case 2: Large Enterprise – Cross-Department AI Adoption Tracking

A large manufacturing company has 50+ Power Pages sites used across HR, Legal, Procurement, and Customer Support departments. The Power Platform CoE (Center of Excellence) team wants to understand which departments are actively adopting Copilot features. Using the Maker Copilot and End-User Copilot analytics in the Copilot Hub, they can track Monthly Active Users (MAU) per site, identify low-adoption areas, and create targeted training programs.

How to Access Copilot Hub for Power Pages

Follow these steps to access the Copilot Hub in the Power Platform Admin Center:

1. Step 1: Go to the Power Platform Admin Center at https://admin.powerplatform.microsoft.com/
2. Step 2: In the left-hand navigation panel, look for and click on ‘Copilot Hub’.
3. Step 3: On the Copilot Hub page, click on the ‘Power Pages’ tab to access product-specific insights and settings.

Analytics & Insights

The Analytics section of the Copilot Hub gives tenant admins a detailed picture of how AI features are being consumed, both by makers building the sites and by end users interacting with the published portals. Admins can toggle between two views:

• Maker Copilot Analytics
• End-User Copilot Analytics

Maker Copilot Analytics

This view provides insights into how site builders (makers and pro developers) use AI features during the site creation process. It covers Studio Copilot (used in the Power Pages Design Studio) and Prodev Copilot (used via the VS Code extension).

Key Metrics Available:

End-User Copilot Analytics

This view focuses on how actual site visitors and end users interact with AI-powered features embedded in published Power Pages portals. It provides feature-level metrics for each AI capability.

Features tracked and their metrics:

Governance Controls for AI Features

The Governance Controls section is where admins exercise full authority over which AI features are available, to whom, and in which environments or sites. This is the most powerful aspect of the Copilot Hub.

Admins can:

• Enable or disable AI features for makers (Studio Copilot, Prodev Copilot)
• Enable or disable AI features for end users (chatbot, search summary, form fill, etc.)
• Apply controls at the environment level or at the individual site level

Step-by-Step: Configuring AI Feature Governance

1. Step 1: In the Copilot Hub, click on the ‘Settings’ link next to the Power Pages tab.
2. Step 2: Use the product filter dropdown and select ‘Power Pages’.
3. Step 3: You will see a list of all available AI features for Power Pages. Click on any feature (e.g., ‘AI Form Fill Assistance’) to configure it.
4. Step 4: A list of all environments in your tenant is displayed, showing Environment Name, Type, Region, and current Status (On/Off).
5. Step 5: Select the environment you want to configure and click ‘Set up / Edit’.
6. Step 6: Choose the appropriate enablement scope:

7. Step 7: Click ‘Save’ to apply the settings.

Important Considerations & Dependencies

When managing AI features in the Copilot Hub, keep the following in mind:

• Tenant-level PowerShell controls (enableGenerativeAIFeaturesForSiteUsers) take precedence. If AI is disabled at tenant level, environment-level settings cannot be configured from the Copilot Hub.
• Only tenant-level admins (Power Platform Administrator or Dynamics 365 Administrator AAD roles) can modify governance settings. Environment-level users cannot access or modify these settings.
• For the Chat Agent feature: If ‘Publish bots with AI’ is disabled at the tenant level, the site Copilot cannot be configured in the Copilot Hub.
• If Bing Search is disabled at the environment level, all Copilot features that depend on Bing search will be unavailable.
• The ‘Move data across regions’ setting at the environment level affects whether Copilot can operate when Azure OpenAI capacity in the local region is insufficient.

Maker Experience When AI Features Are Disabled

When a tenant admin disables AI features, makers building sites in the Design Studio will immediately see the impact:

• If a Maker Copilot feature (Studio or Prodev Copilot) is disabled, makers see an in-product message informing them the feature has been turned off by an admin, with a prompt to reach out to their administrator.
• If End-User AI features (chatbot, search summary, form fill) are disabled, the configuration options for those features in the Design Studio appear greyed out with a message indicating they are managed by the admin.

End-User Experience When AI is Blocked

When generative AI features are turned off for a site’s end users, the experience gracefully falls back to the standard non-AI version. For example:

• Users see a standard keyword-based search instead of an AI-powered search summary.
• Form fields appear as regular fields — no AI auto-fill from document upload.
• No chatbot is presented if the Chat Agent has been disabled.

Importantly, users do not see any messaging about organizational policies or governance controls — the fallback is seamless

Conclusion

The Copilot Hub for Power Pages is a powerful, much-needed addition to the Power Platform Admin Centre. As AI features become mainstream in Power Pages portals — from intelligent chatbots to AI-assisted form filling — the ability to monitor, analyse, and govern these capabilities at scale becomes critical for enterprise IT and compliance teams.

To summarize what the Copilot Hub offers:

• Centralized analytics for both Maker and End-User Copilot features
• Feature-level governance at both environment and site granularity
• Transparent feedback to makers when features are restricted
• Seamless fallback for end users when AI is disabled

Whether you are an IT admin rolling out Power Pages across a large enterprise, a compliance officer in a regulated industry, or a Power Platform CoE lead tracking AI adoption — the Copilot Hub gives you the visibility and control you need.

The post Enhancing Power Pages Experience with Copilot Hub first appeared on Microsoft Dynamics 365 CRM Tips and Tricks.

In customer service operations, teams often struggle to get a clear understanding of case performance and SLA compliance in real time. Users usually need to open multiple records, review reports manually, and switch across screens just to identify which cases require immediate attention.

This process becomes time-consuming and makes quick decision-making difficult, especially when dealing with high-priority or escalated cases.

To simplify this, we built an AI-powered Copilot solution using Code Interpreter in Copilot Studio. The solution can analyze live case data, generate SLA dashboards, create visual insights, and even produce downloadable Excel reports directly from conversational queries.

Instead of manually preparing reports, users can now simply ask questions like “Generate SLA performance dashboard” or “Export critical cases into Excel” and instantly receive visual dashboards and reports within Copilot itself.

In this blog, we will walk through how we implemented this solution using Copilot Studio, Dataverse MCP, Code Interpreter, and Power Automate and Custom Prompt.

Step By Step Implementation of Agent :

Step 1: Prepare Sample Case and SLA Data in Dynamics 365

To demonstrate the complete SLA analytics scenario, we first prepared sample customer service case data inside Dynamics 365 Customer Service Hub. The data includes cases with different priorities such as Critical, High, Normal, and Low, along with various statuses like Active and Resolved.

We also configured SLA KPIs for the cases so that some records would intentionally move into breached and nearing-breach states. This helped us simulate a realistic customer service environment where managers need quick visibility into SLA performance and escalated cases.

Step 2: Create the Customer Service Bot and Configure Agent Instructions

After preparing the case and SLA data, we created a Customer Service Bot in Copilot Studio and configured detailed agent instructions. The agent was designed to understand customer service-related queries, retrieve real-time case data, identify SLA breaches, and provide operational insights dynamically.

Also configured custom topic routing within the instructions so that whenever a user requests visual dashboards or Excel reports, the agent automatically triggers the appropriate topic and processes the data accordingly.

Step 3: Configure the Microsoft Dataverse MCP Server

To connect the Copilot agent with Dynamics 365 data, we added and configured the Microsoft Dataverse MCP Server. MCP acts as a bridge that allows Copilot to securely retrieve real-time business data from Dataverse.

To Enable : Tool -> Dataverse -> Microsoft Dataverse MCP Server

For this implementation, we enabled only read-based operations such as querying and retrieving records, ensuring that the agent can analyze data safely without creating, updating, or deleting any records.

Step 4: Enable Code Interpreter and Deep Reasoning

Next, we enabled Code Interpreter and Deep Reasoning from the agent settings in Copilot Studio. Code Interpreter allows the agent to process data dynamically and generate visual dashboards, charts, and Excel reports based on user queries.

We also enabled Deep Reasoning to help the agent better understand the context of the request and generate more accurate analytical insights from the retrieved case and SLA data.

Step 5: Create a Custom Topic for Dashboard Requests

After configuring the agent, we created a custom topic in Copilot Studio to handle visual dashboard requests. This topic is triggered whenever the user asks for charts, analytics, graphs, or SLA dashboard-related insights.

Inside the topic, we added input variables to capture the user request and the case data retrieved from Dataverse. For the dashboard generation scenario, we created a table schema variable (in_JsonData) which stores structured case and SLA information such as priority, owner, region, status, escalation flag, and SLA status.

This structured data is then passed further into the dashboard generation process for analysis and visualization.

Next, we created Custom Prompt , To create go to make.powerapps.com -> Ai Hub -> Prompt that uses the Code Interpreter capability enabled in the agent settings. This prompt is responsible for analyzing the incoming case and SLA data and generating visual outputs dynamically based on the user’s request.

Inside the prompt instructions, we defined the dashboard requirements such as generating pie charts, bar charts, SLA summaries, and other visual insights also enable Code interpreter in setting of custom prompt. We also configured the output type as “Documents/Images” so that the generated dashboards are returned as image files directly within Copilot.

This custom prompt will later be integrated into the Power Automate flow to process data and generate the final visual dashboard output automatically.

Step 7: Build the Power Automate Flow

In the Power Automate flow, we first receive the user question and structured case data from the Copilot topic as input parameters. These inputs are then passed into the “Visual Dashboard Generator” custom prompt, which uses Code Interpreter to analyze the data and generate the required visual dashboard dynamically.

Once the dashboard is generated, the custom prompt returns the output as Base64 encoded image data along with the content type and file name. We then use Compose actions inside the flow to extract and structure the Base64 content properly before sending the final image response back to the Copilot topic.

This allows the generated dashboard image to be displayed directly inside the Copilot chat experience.

Step 8: Connect the Copilot Topic to the Power Automate Flow

Inside the Copilot topic, we configured the Power Automate action to pass both the user query and the structured case data into the flow. The LastMessage.Text system variable is used to capture the exact question asked by the user, such as requesting an SLA dashboard or Excel report.

For the case data, we used the JSON(Topic.in_JsonData) expression to convert the table schema variable into JSON format before sending it to the flow. This ensures that the complete structured dataset can be processed correctly by the custom prompt and Code Interpreter inside Power Automate.

The flow then returns the generated file name, content type, and Base64 image content back to the Copilot topic then we use that same in the Message action with type file and provide all 3 options for displaying the dashboard output directly in the chat.

Step 9: Integrate with Microsoft Teams and Publish

Finally, we integrated the Copilot agent with Microsoft Teams, allowing users to access dashboards, reports, and SLA insights directly within the Teams interface.

Then Publish the agent after configuration and open the agent in Teams Chat and start asking question:

As shown below, the Copilot agent successfully generated a real-time SLA Performance Dashboard directly within the chat interface based on the user query. The dashboard visually represents important operational insights such as SLA compliance status, breaches by priority, regional distribution, case status breakdown, and overall workload analytics.

Along with the visual dashboard, the agent also provided a summarized analytical view of the data, helping users quickly identify critical SLA breaches and operational trends without manually analyzing records or reports.

Step 10: Implement Excel Report Generation

Similar to the Visual Dashboard generation process, we also implemented an AI-powered Excel Report generation feature using the same topic-flow architecture and custom prompt approach. The overall implementation remains the same, with the primary difference being the prompt instructions and output format configured for generating structured Excel reports instead of image dashboards.

Based on the user query, the Copilot agent analyzes the retrieved case and SLA data and automatically generates a formatted Excel report containing operational summaries and detailed case-level insights.

As shown below, the generated Excel report includes multiple analytical sections such as overall case overview, SLA performance metrics, priority-wise case analysis, escalation details, and detailed case records. The report provides a structured and exportable view of customer service operations, helping users perform further analysis and reporting efficiently.

Conclusion

In this blog, we implemented an AI-powered customer service analytics solution using Copilot Studio, Code Interpreter, and Dataverse MCP Server. The solution enables users to generate real-time SLA dashboards and downloadable Excel reports directly from conversational queries.

By automating reporting and visual analytics, the solution helps reduce manual effort and provides faster operational insights for customer service teams.

FAQs

What is Dynamics 365 AI Dashboard with Code Interpreter in Copilot Agents?

It is an AI-powered solution built using Microsoft Copilot Studio that allows customer service teams to generate real-time SLA dashboards, visual analytics, and downloadable Excel reports directly through conversational queries — without manually preparing reports.

What problem does this Copilot solution solve?

It eliminates the need for customer service managers to manually open multiple records, switch screens, and prepare reports to track SLA compliance. Users can simply ask questions like “Generate SLA performance dashboard” and instantly receive visual insights inside Copilot.

What is Code Interpreter in Copilot Studio?

Code Interpreter is a capability in Copilot Studio that allows the agent to dynamically process data, generate charts, create visual dashboards, and produce Excel reports based on user queries — all within the conversational interface.

What is Deep Reasoning in Copilot Studio and why is it enabled?

Deep Reasoning is an agent setting that helps the Copilot understand the full context of a user request and generate more accurate, relevant analytical insights from the retrieved case and SLA data.

Where can users access this Copilot solution?

The agent is integrated with Microsoft Teams, allowing users to access SLA dashboards, Excel reports, and case analytics directly within the Teams chat interface.

The post Dynamics 365 AI Dashboards and Excel Reporting with Code Interpreter in Copilot Agents first appeared on Microsoft Dynamics 365 CRM Tips and Tricks.

When building Power Apps code apps, one of the most powerful things you can do is reach directly into Dataverse to trigger business logic. Whether it is routing a support ticket to the right queue, checking who the current user is, or running a custom API operation, Dataverse actions and functions are the engine behind most enterprise workflows.

In the past, calling these operations required manually writing Web API fetch calls, constructing the right URLs, and handling typed responses by hand. It worked, but it was slow, error-prone, and hard to maintain as schemas evolved.

Microsoft has now introduced a much cleaner developer experience through the Power Apps npm CLI. With just two commands — find-dataverse-api and add-dataverse-api — you can discover operations in your Dataverse environment, generate fully typed TypeScript service classes, and call them directly from your code app with confidence.

This blog walks through exactly how to do that, using a real-world scenario: a support team that needs to automatically route incoming cases to the correct queue based on priority.

Client Scenario: Automated Case Routing

A client running a customer support operation on Dynamics 365 came to us with a specific pain point. Their agents were starting every shift by manually scanning a shared queue, finding cases relevant to them, and self-assigning each one individually through the Dynamics 365 UI. With dozens of queued cases at any given time, agents were spending the first 15–20 minutes of every shift just on assignment, before they had even looked at a single customer issue.

They needed a code app that displayed all cases currently sitting in the queue and allowed an agent to pick and assign any case to themselves with a single click. The assignment logic already existed as a Dataverse bound action called PickFromQueue. The challenge was invoking it cleanly from a modern Power Apps code app.

The requirements the client laid out were straightforward:

• View all active cases in a clean, filterable list
• Select a case from the queue and assign it to yourself with one click
• Show who is currently logged in so agents can confirm their session
• Ensure all operations are type-safe and maintainable

This is exactly the kind of scenario the add-dataverse-api command was built for.

Prerequisites

Before following this guide, make sure the following are in place:

• A Power Apps code app initialised using npx power-apps init
• The @microsoft/power-apps package at version 1.1.1 or later in your package.json
• An active CLI session (the CLI will prompt you to authenticate if not already logged in)
• Access to the Dataverse environment that contains the operations you want to call
• js installed on your machine (version 18 or later recommended)

Note: Run npm list @microsoft/power-apps to confirm the package version (1.1.1 or later). The CLI version (shown by npx power-apps –version) may differ from the package version..

Step 1: Discover Available Dataverse Operations

The first step is to find out which Dataverse operations are available in your environment. The find-dataverse-api command performs a case-insensitive substring search against the operation names in your connected environment.

For this scenario, we need two operations. The first is WhoAmI, which identifies the current logged-in user. The second is PickFromQueue, which picks a case from a queue and assigns it to a specified user.

Finding WhoAmI

Run the following command in your terminal from inside the code app project folder:

npx power-apps find-dataverse-api --search "WhoAmI"

The output will show the operation name, its kind (Function or Action), and its return type:

Finding PickFromQueue

Next, search for the PickFromQueue action:

npx power-apps find-dataverse-api --search "PickFromQueue"

You will see something like this:

Notice that PickFromQueue is a bound action — it is bound to mscrm.queueitem, meaning it must be called with the GUID of the queue item record as its first argument. This is an important distinction that affects how the generated service method works, which we will cover shortly.

If you want to inspect the raw JSON output for scripting purposes, add the –json flag:

npx power-apps find-dataverse-api --search "PickFromQueue" --json

Step 2: Add the Operations to Your Code App

Once you have confirmed the operation names, use the add-dataverse-api command to wire them into your project. This command does several things automatically:

• Fetches the full operation definition from your environment’s Dataverse metadata endpoint
• Creates a schema file at the configured schema path
• Generates TypeScript model files for any entities referenced in the operation
• Generates a typed service class for the operation
• Updates power.config.json with the necessary database reference
• Regenerates dataSourcesInfo.ts to include the new operation

Adding WhoAmI

npx power-apps add-dataverse-api --api-name WhoAmI

On success, you will see:

Adding PickFromQueue

npx power-apps add-dataverse-api --api-name PickFromQueue

Or using the short alias:

npx power-apps add-dataverse-api -n PickFromQueue

Once both commands complete, your project structure will include new generated files. Here is a summary of what was created or updated:

Step 3: Use the Generated Services in Your App

With the service classes generated, you can now import and call them directly in your application code. The CLI handles all the Web API URL construction, authentication headers, and response parsing behind the scenes.

Calling WhoAmI

Import the WhoAmIService from the generated services directory and call it to retrieve the current user’s identity:

import { WhoAmIService } from './generated/services/WhoAmIService';

const userInfo = await WhoAmIService.WhoAmI() as any;

const currentUserId = userInfo.UserId;

const businessUnitId = userInfo.BusinessUnitId;

const orgId = userInfo.OrganizationId;

The result object contains three GUIDs — UserId, BusinessUnitId, and OrganizationId — all fully typed. In the case routing app, we use the UserId to display which agent is currently logged in, giving the team lead confidence before performing any routing action.

Calling PickFromQueue

The PickFromQueue action is a bound operation, which means the generated service method takes the queue item GUID as its first argument, followed by the operation parameters:

import { PickFromQueueService } from './generated/services/PickFromQueueService';
const handlePickCase = async (queueItemId: string, currentUserId: string) => {

const systemUser = {

'@odata.type': 'Microsoft.Dynamics.CRM.systemuser',

systemuserid: currentUserId

};

await PickFromQueueService.PickFromQueue(

queueItemId,    // GUID of the queue item (first arg for bound actions)

systemUser,     // The system user to assign the case to

true            // RemoveQueueItem — remove from queue after picking

);

console.log('Case picked from queue successfully');

};

The function picks the case from the queue and assigns it to the specified user. When RemoveQueueItem is true, the item is automatically removed from the queue to prevent duplicate assignments.

Note: For bound operations, the first argument is always the GUID of the record the action is bound to. In this case, PickFromQueue is bound to mscrm.queueitem, so the first argument is the queue item ID.

Step 4: Build the Case Routing UI

With both services wired up, the final step is to build the actual interface the team leads will use. The component needs to show a list of open cases, allow selection, and trigger the routing action.

Below is a simplified version of how the component comes together:

import { useEffect, useState } from 'react';

import { WhoAmIService } from './generated/services/WhoAmIService';

import { PickFromQueueService } from './generated/services/PickFromQueueService';

// Sample cases in queue (in production, fetch from Dataverse)

const queuedCases = [

{ id: 'CAS-1001', title: 'Printer not working',    queueItemId: '< queue-item-guid-1 >' },

{ id: 'CAS-1002', title: 'Password reset request', queueItemId: '< queue-item-guid-2 >' },

{ id: 'CAS-1003', title: 'Software installation',  queueItemId: '< queue-item-guid-3 >' },

];

export const CaseRoutingApp = () => {

const [currentUserId, setCurrentUserId] = useState('');

const [routedCases, setRoutedCases] = useState<Record<string, boolean>>({});

useEffect(() => {

WhoAmIService.WhoAmI().then((r: any) => setCurrentUserId(r.UserId));

}, []);

const handlePickCase = async (queueItemId: string, caseId: string) => {

const systemUser = {

'@odata.type': 'Microsoft.Dynamics.CRM.systemuser',

systemuserid: currentUserId

};

await PickFromQueueService.PickFromQueue(queueItemId, systemUser, true);

setRoutedCases(prev => ({ ...prev, [caseId]: true }));

};

return ( /* your JSX here */ );

};

Once you are happy with the result in local preview, run:

npx power-apps push

This deploys the app to your Dataverse environment and makes it available inside the model-driven app.

Important Notes and Common Pitfalls

A few things to keep in mind as you work with this feature:

Bound vs. Unbound Operations

The distinction between bound and unbound operations matters for how you call the generated service method. Bound operations always take an id: string as the first argument (the GUID of the record the operation is bound to). Unbound operations, like WhoAmI, take only the declared parameters.

The CLI detects the operation type automatically and generates the method signature accordingly. You do not need to configure anything manually.

Re-running add-dataverse-api is Safe

If the operation’s signature changes in your environment — for example, a developer added a new optional parameter — simply re-run the same command:

npx power-apps add-dataverse-api --api-name PickFromQueue

The command is idempotent. It overwrites the schema and regenerates the service class with the latest definition. It will not create duplicate entries in power.config.json, and it will not overwrite entity schema files that already exist.

Conclusion

The add-dataverse-api command is a significant quality-of-life improvement for developers building Power Apps code apps. Instead of handwriting Web API calls, managing URL patterns for bound vs. unbound operations, and manually typing response objects, you get fully generated, type-safe service classes in seconds.

For the support team in our scenario, the result was exactly what the client needed. Cases are now routed with a single click, the correct agent identity is confirmed before any action is taken, and the development time was a fraction of what it would have taken with raw Web API calls.

Whether you are calling WhoAmI to verify the current session, triggering a bound action like PickFromQueue to execute business logic, or invoking a custom operation your team has built, the CLI handles the scaffolding so you can focus on building the experience.

FAQs

What is add-dataverse-api in Power Apps code apps?

The add-dataverse-api command is a Power Apps CLI feature that generates fully typed TypeScript service classes for Dataverse actions and functions. It eliminates the need to manually write Web API fetch calls when building Power Apps code apps.

How do you call Dataverse actions from a Power Apps code app?

You can call Dataverse actions in a Power Apps code app by using the Power Apps npm CLI commands find-dataverse-api and add-dataverse-api. These commands generate typed service classes that let developers invoke Dataverse actions directly in TypeScript.

What is the difference between bound and unbound Dataverse actions?

Bound Dataverse actions are linked to a specific Dataverse table or record and require a record GUID as the first parameter. Unbound actions are standalone operations that do not require a record reference. For example, PickFromQueue is bound, while WhoAmI is unbound.

The post Calling Dataverse Actions and Functions from Power Apps Code Apps first appeared on Microsoft Dynamics 365 CRM Tips and Tricks.

Managing enterprise applications across Microsoft Power Platform and Dynamics 365 can be challenging for administrators. Teams must continuously monitor storage, licensing, environmental health, operational failures, and platform updates across multiple systems.

As organizations increasingly depend on these platforms for business-critical operations, even a minor issue can quickly disrupt users and impact overall business processes if not identified and resolved in time.

Consider a company using Power Apps and Dataverse for customer service operations across multiple departments. One day, Dataverse storage begins nearing its limit. Because Dataverse throttles performance when storage exceeds allocated capacity, workflows begin slowing down, users face delays while creating records, and some automations stop working properly.

Because the alert is often buried across emails, dashboards, or separate monitoring tools, administrators may not notice the issue immediately. By the time teams investigate, business operations are already impacted.

To address challenges like this, Microsoft introduced Notifications and Announcements (Preview) in the Power Platform admin center.

This feature provides a centralized and proactive administration experience where admins can:

• Monitor tenant health directly from the admin center
• Identify operational issues earlier
• Stay informed about Microsoft platform updates
• Respond faster to critical alerts
• Reduce dependency on multiple monitoring systems

Instead of manually searching across different portals, administrators can now review important operational alerts and product communications directly within their daily workflow. For enterprise teams, this means less firefighting and more proactive control.

Requirements to Access Notifications and Announcements

During the preview phase, access to Notifications () and Announcements () is limited to specific administrator roles in Microsoft Entra ID.

Only users assigned one of the following roles can access these features inside the Power Platform admin center:

• Power Platform Administrator
• Dynamics 365 Administrator
• Global Administrator

Follow the steps to assign required role

• Open the Microsoft Entra Admin Center and sign in with an administrator account.
• In the left navigation pane, go to Identity → Users.
• Select the user who needs access to Notifications and Announcements in the Power Platform admin center.
• Open the user profile, then select Assigned roles or Manage roles.
• Click Add assignments to assign a new administrator role. And
• Assign one of the following Microsoft Entra administrator roles:

1. Power Platform Administrator
2. Dynamics 365 Administrator
3. Global Administrator

Save the changes and sign in to the Power Platform admin center. The user will then be able to access the Notifications () and Announcements () icons from the top toolbar.

Notifications ()

Notifications help administrators monitor important operational issues directly inside the Power Platform admin center. These alerts are tenant-specific and help admins quickly identify issues related to environment health, storage, licensing, compliance, or other operational risks.

For example, if Dataverse storage starts nearing its limit, administrators can take action before workflows, apps, or business operations are affected.

Notifications may include:

• License or capacity alerts
• Dataverse storage warnings
• Compliance or environment-related issues

Admins can access notifications directly from the Bell icon () available in the upper-right corner of the Power Platform admin center, as shown in the screenshot below.

The Notifications pane displays:

• Unread alerts
• Notification summaries
• Severity indicators such as Info, Warning, or Critical
• Timestamps for newly generated alerts

The Notifications pane also categorizes alerts by severity to help administrators prioritize issues more effectively:

• Info – Informational updates or recommendations that do not require immediate action
• Warning – Potential risks or approaching limits that may require attention soon
• Critical – Urgent issues or service disruptions that require immediate action

As shown below, notifications are currently available in this environment because notifications appear only when tenant-level operational events or alerts are generated.

Selecting a notification opens the full message and may provide direct links to related areas such as Capacity, Licensing, or Environments, helping administrators investigate issues faster.

How to Act on a Notification (Example):

If you receive a Dataverse storage warning, clicking the notification typically links directly to the Capacity page. From there, you can view usage breakdowns, purchase additional storage add-ons, or identify tables with stale data to purge. This creates a clear path from alert to resolution.

Admins can also:

• Mark notifications as read
• Dismiss notifications from the list
• Receive toast notifications during sign-in or page refresh for newly generated alerts

About Toast Notifications:

Toast notifications are temporary pop-up messages that appear briefly in the corner of your screen when you sign in or refresh the page. They ensure you don’t miss new critical alerts even if you don’t have the Notifications pane open. After a few seconds, they disappear automatically without disrupting your workflow.

Overall, Notifications improve operational visibility and help organizations respond to platform issues more proactively.

Announcements ()

Announcements help administrators stay updated with the latest Microsoft platform updates directly inside the Power Platform admin center. Unlike Notifications, which focus on operational issues, Announcements are mainly designed for product updates, feature releases, webinars, and upcoming platform changes.

Administrators no longer need to rely entirely on multiple Microsoft blogs and documentation portals to stay informed about important updates.

Announcements may include:

• Public preview features
• General Availability (GA) updates
• Product enhancements
• Microsoft events and webinars
• Release notes and learning resources

Admins can access Announcements from the Megaphone icon () in the top-right corner of the admin center, as shown in the screenshot below.

The announcements panel displays recent updates, summaries, and publication details to help administrators quickly review important Microsoft communications. As shown below, announcements are currently available in this environment because announcements appear based on Microsoft product communications and preview availability.

Another useful benefit is that announcements often include direct links to Microsoft Learn documentation, release notes, and product blogs, helping organizations understand and plan for upcoming changes more efficiently.

Notifications vs Announcements

Although Notifications and Announcements are available together inside the Power Platform admin center, both serve different purposes.

Consider a real-world example:

A company notices that Dataverse storage is reaching its limit. Administrators receive a Warning notification, allowing them to take action before workflows, apps, or automations are affected. This is an operational alert that directly impacts the organization’s environment.

At the same time, Microsoft may publish an Announcement about an upcoming Power Platform feature release or licensing update. While this does not require immediate action, it helps administrators prepare for future platform changes and adoption planning.

In simple terms:

• Notifications help admins monitor and respond to operational or tenant-level issues.
• Announcements help admins stay informed about Microsoft product updates, releases, and upcoming changes.

Together, these features provide a more centralized and proactive administration experience inside the Power Platform admin center.

Relationship with Microsoft 365 Message Center

The Power Platform admin center Notifications are designed to complement existing Microsoft 365 monitoring and communication systems rather than replace them. Together, they help administrators get a complete view of both tenant health and platform-wide updates.

For organization-wide updates such as feature rollouts, deprecations, breaking changes, or service announcements, administrators continue to rely on the Microsoft 365 Message Center. It is the primary source for Microsoft 365-wide communications that may impact multiple services across an organization, including Power Platform.

In contrast, Power Platform Notifications focus on tenant-specific operational alerts. These alerts help administrators quickly identify and respond to issues related to environment health, storage capacity, licensing, compliance, or service disruptions that directly affect their Power Platform environments.

For example, if a Dataverse environment is nearing its storage limit, administrators receive a notification within the Power Platform admin center and can take action before it impacts applications, workflows, or users.

In simple terms:

• Microsoft 365 Message Center is used for planned changes, updates, and Microsoft-wide communications.
• Power Platform Notifications are used for real-time, tenant-level operational issues.

Together, they provide better visibility by combining long-term platform communication with real-time operational monitoring inside the Power Platform admin center.

Conclusion:

Power Platform admin center Notifications and Announcements (Preview) provide administrators with a more proactive and centralized management experience.

Notifications help teams respond quickly to tenant-level operational issues such as storage, licensing, and environment risks, while Announcements keep administrators informed about upcoming Microsoft updates, features, and platform changes.

Together, these features improve visibility, streamline administration, and complement the Microsoft 365 Message Center for a more complete view of both operational issues and platform updates.

FAQs

1. What are Notifications in the Power Platform admin center?

Notifications are tenant-specific operational alerts that help administrators monitor issues related to storage, licensing, environment health, compliance, and service disruptions within Microsoft Power Platform.

2. What are Announcements in the Power Platform admin center?

Announcements are informational updates from Microsoft that include feature releases, public previews, product enhancements, webinars, release notes, and upcoming platform changes.

3. Who can access Notifications and Announcements in the Power Platform admin center?

During the preview phase, only users assigned the following Microsoft Entra administrator roles can access these features:

• Power Platform Administrator
• Dynamics 365 Administrator
• Global Administrator

4. How are Notifications different from Microsoft 365 Message Center updates?

Microsoft 365 Message Center provides organization-wide updates such as feature rollouts and planned changes, while Power Platform Notifications focus on real-time tenant-level operational alerts like storage limits, licensing issues, or environment health warnings.

5. Can Notifications help monitor Dataverse storage capacity?

Yes. Notifications can alert administrators when Dataverse storage approaches allocated capacity limits, helping teams take corrective action before workflows, applications, or automations are impacted.

Power Platform Administrator Dynamics 365 Administrator Global Administrator" } },{ "@type": "Question", "name": "How are Notifications different from Microsoft 365 Message Center updates?", "acceptedAnswer": { "@type": "Answer", "text": "Microsoft 365 Message Center provides organization-wide updates such as feature rollouts and planned changes, while Power Platform Notifications focus on real-time tenant-level operational alerts like storage limits, licensing issues, or environment health warnings." } },{ "@type": "Question", "name": "Can Notifications help monitor Dataverse storage capacity?", "acceptedAnswer": { "@type": "Answer", "text": "Yes. Notifications can alert administrators when Dataverse storage approaches allocated capacity limits, helping teams take corrective action before workflows, applications, or automations are impacted." } }] }

The post Power Platform Admin Center Notifications and Announcements (Preview) first appeared on Microsoft Dynamics 365 CRM Tips and Tricks.

Over the past few months, Copilot has become one of the most talked-about features in the Microsoft ecosystem. But one thing still confuses many people:

There are actually two different Copilot experiences available in Microsoft 365.

• Microsoft 365 Copilot – the paid add-on
• Copilot Chat – the free chat experience included with Microsoft 365

At first glance, they look almost identical. Both allow you to type prompts and get responses from AI.

However, when you try to use them in a real business scenario, especially inside CRM, the difference becomes very clear.

Recently, I experimented with both tools using a practical Dynamics 365 CRM scenario, and the results made the distinction crystal clear.

If you work in Sales, Customer Service, Consulting, or Project Delivery, this comparison will help you understand which Copilot actually makes a difference.

The Problem: AI That Can’t See Your Work

In most organizations, information about a customer is spread across multiple systems.

For example, in a typical CRM workflow you might have:

• Customer emails in Outlook
• Meeting notes from calendar events
• CRM notes and activities
• Service cases
• Tasks and follow-ups
• Internal discussions
• Documents and attachments

When you ask AI to summarize a customer opportunity or identify risks, it needs access to all of this context.

But not every Copilot has that visibility.

To understand the difference, I created a simple real-world test scenario inside CRM.

What Is the Difference Between Copilot Chat and Microsoft 365 Copilot?

Copilot Chat is a general-purpose AI assistant that works only with user-provided prompts.

Microsoft 365 Copilot, on the other hand, integrates with Microsoft Graph to access organizational data such as emails, meetings, documents, and CRM records allowing it to generate context-aware insights.

The Use Case: A Real CRM Opportunity

To test both Copilot experiences, I recreated a realistic opportunity inside CRM.

Here’s the setup:

• Account: Contoso Retail Group
• Primary Contact: Sarah Thompson
• Opportunity: Contoso POS Upgrade Project

To simulate a real project, I added different pieces of information across the system:

• Email conversations with the engineering team discussing migration constraints
• Opportunity notes describing the migration strategy and potential risks
• Meeting notes covering API readiness and dashboard activation timelines
• Tasks related to preparing proposals and scheduling pilot migrations
• A service case linked to the account about previous POS downtime

In short, this was a normal customer project scenario where information exists in many places.

The Prompt I Asked Both Copilots

Once everything was ready, I asked both copilots the exact same question:

“Summarize the Contoso POS Upgrade Opportunity using emails, notes, meeting notes, case details, and tasks. Include customer concerns, risks, and next steps.”

What Happened with Copilot Chat

When I asked Copilot Chat, the response was polite but limited.

It replied that Sorry, I don’t know that one yet, but I’m always learning.

 In simple terms, Copilot Chat had no visibility into the opportunity context.

Copilot Chat is still useful for tasks like:

• Writing content
• Brainstorming ideas
• Creating templates or plans
• Explaining general concepts

But when it comes to understanding your day-to-day work inside business systems, it simply doesn’t have access to the necessary information.

What Happened with Microsoft 365 Copilot

Next, I ran the same prompt using Microsoft 365 Copilot.

The difference was immediate.

In simple terms, Microsoft 365 Copilot understands your work context by connecting to organizational data across the Microsoft ecosystem through Microsoft Graph. This allows it to automatically gather insights from emails, meetings, documents, notes, tasks, files, and conversations within the Microsoft 365 environment. Using this connected context, Copilot was able to generate a much richer and more meaningful summary of the opportunity.

The output included insights such as:

From Emails

• Planned migration downtime window
• Deployment approach using store batches
• Customer concerns about weekend disruptions

From CRM Notes

• Engineering feedback on legacy scripts
• Risk related to unsynced transactions
• Offline billing requirements

From Meeting Notes

• API integration readiness
• Estimated dashboard activation time

From Tasks

• Preparing customer update communication
• Scheduling pilot migration
• Updating proposal documentation

From the Service Case

• Previous POS downtime incidents
• Early signs of customer frustration

The summary felt less like a chatbot response and more like something a project analyst might prepare before a stakeholder meeting.

Copilot Chat vs Microsoft 365 Copilot: Key Differences

Feature	Copilot Chat	Microsoft 365 Copilot
Access to CRM Data	No	Yes
Microsoft Graph Integration	No	Yes
Context Awareness	Primarily in‑chat only	High
Data Sources	Manual input only	Emails, meetings, CRM, tasks
Best Use Case	Writing & brainstorming	Business workflows & decision-making

Why This Matters for CRM Professionals:

CRM work rarely lives in a single record.

Important information about a customer often exists across:

• emails
• meetings
• internal discussions
• notes
• cases
• tasks

To truly understand the situation, you need to connect all those pieces together.

That’s exactly what Microsoft 365 Copilot is designed to do.

Instead of analyzing one piece of information at a time, it can combine insights from multiple sources and provide a complete picture of the situation.

Copilot Chat, on the other hand, only understands the information you manually paste into the chat window.

Final Thoughts

Copilot Chat and Microsoft 365 Copilot may look similar, but they serve very different purposes.

Copilot Chat is great for general AI assistance like writing, brainstorming, and answering questions.

Microsoft 365 Copilot, on the other hand, connects directly to your organization’s data and understands the context of your work.

For professionals working in sales, consulting, customer service, or project delivery, that difference can dramatically improve productivity.

Instead of manually gathering information from multiple systems, Microsoft 365 Copilot helps you see the full picture and act faster.

And in customer-facing roles, having that complete context can make all the difference.

FAQ: Copilot Chat vs Microsoft 365 Copilot

Q: Can Copilot Chat access Dynamics 365 CRM data?
No, Copilot Chat cannot access CRM data unless you manually provide it in the prompt.

Q: What makes Microsoft 365 Copilot different?
Microsoft 365 Copilot integrates with Microsoft Graph to access emails, meetings, documents, and CRM data, enabling context-aware insights.

Q: Is Microsoft 365 Copilot worth it for CRM users?
Yes, especially for sales, service, and consulting teams who rely on insights across multiple systems.

The post Microsoft 365 Copilot vs Copilot Chat: Key Differences for Dynamics 365 CRM Users first appeared on Microsoft Dynamics 365 CRM Tips and Tricks.

Organizations frequently receive employee requests for training programs, certifications, or skill-development courses. Traditionally, these requests go through manual review and approval processes which can delay decision making and create administrative overhead.

With Advanced Approvals in Microsoft Copilot Studio, it is possible to automate such decisions using AI. Instead of relying on human approval stages, AI can evaluate the request details and decide whether the request should be approved or rejected based on predefined criteria.

In this article, we will build a Training Request Approval System where:

• A user creates a training request record in Dataverse
• An AI approval stage evaluates the request
• The AI automatically approves or rejects the request

This implementation demonstrates how AI-driven approvals can automate business decisions without human intervention.

Prerequisites

Before starting, ensure the following are available:

• Access to Microsoft Copilot Studio
• A Power Platform environment with Dataverse enabled
• Basic knowledge of Dataverse tables and Copilot Studio agent flows

Solution Overview

The workflow implemented in this article follows a simple structure.

1. Employee submits a training request
2. The request is stored in Dataverse
3. AI evaluates the request
4. The system updates the approval status

This removes the need for manual manager approvals and allows faster decision making.

Step 1: Create a Dataverse Table for Training Requests

First, create a Dataverse table that will store the training requests.

Example table: Training Requests

Suggested columns:

This table will be used by the AI flow to read and update request details.

Step 2: Create an Agent Flow in Copilot Studio

Navigate to Copilot Studio → Agent Flows and create a new flow.

Agent flows allow you to automate processes using AI and actions connected to data sources like Dataverse.

In this implementation, the agent flow will:

• Retrieve the training request
• Evaluate the request using AI
• Update the request status.

Agent Flow creation screen in Copilot Studio

Step 3: Configure the Multistage Approval Step

Add the Run a multistage approval action in the flow.

This feature allows AI to evaluate requests based on specific instructions.

Since this implementation focuses on AI-only approval, no manual stages are added.

The flow will only contain the Evaluate Request AI stage.

Run a multistage approval (preview) configuration screen

Step 4: Define AI Evaluation Instructions

Inside the Evaluate Request step, define clear instructions for the AI model so it knows how to evaluate the request.

Example instructions:

Evaluate the employee training request and decide whether it should be Approved or Rejected.

APPROVE the request if ALL of the following are true :

– The trainingCost <= 1000.00

– trainingStartDate is after the date the course is purchased (i.e. coursePurchaseDate)

– The request contains all required details including employeeName, courseName, trainingCost, and trainingStartDate.

REJECT the request if any of the above are false.

Note: Here trainingCost, trainingStartDate, employeeName, courseName, coursePurchaseDate are dynamic fields as shown below in the image

These instructions guide the AI model to consistently evaluate each training request.

AI instruction configuration inside the Evaluate Request stage

Step 5: Update the Dataverse Record

After the AI evaluates the request, configure the next step in the flow to update the Dataverse record.

Based on the AI decision:

• If Approved → Update Approval Status to Approved
• If Rejected → Update Approval Status to Rejected

This ensures the final decision is stored directly in Dataverse.

Dataverse Update Row action in the flow

Testing the AI Approval Process

Once the flow is configured:

1. Create a new training request record
2. Trigger the agent flow
3. Observe the AI evaluation
4. Verify that the Approval Status updates automatically

This demonstrates how AI can independently make approval decisions based on defined rules.

Dataverse Update Row action flow when all conditions are met / true

Dataverse Update Row action flow when all conditions are not met / false

Example training request record before and after AI evaluation

Challenges You May Encounter

While implementing AI approvals in Copilot Studio, you may encounter some configuration challenges.

1.Writing Effective AI Instructions

The AI model relies heavily on the instructions provided. If instructions are vague, the decision may be inconsistent.

To avoid this:

• Clearly define approval and rejection conditions
• Keep the logic simple and structured.

2.Mapping Dataverse Fields

Incorrect field mapping between the agent flow and Dataverse may prevent the AI from reading request data correctly.

Always verify:

• Column names
• Data types
• Input parameters passed to the AI stage.

3.Understanding AI Decision Outputs

The AI stage returns structured output which must be correctly interpreted when updating Dataverse records. Improper condition checks may cause incorrect status updates.

4.Preview Feature Limitations

The Multistage Approval feature is currently in preview, so some UI elements or configurations may change over time.

Benefits of AI-Driven Approvals

Implementing AI-based approvals provides several advantages:

• Faster decision making
• Reduced dependency on manual approvals
• Scalable automation
• Consistent evaluation logic
• Seamless integration with Dataverse

Conclusion

Advanced approvals in Microsoft Copilot Studio open new possibilities for automating decision-based workflows. In this example, we built a Training Request Approval System where AI evaluates each request and determines whether it should be approved or rejected.

FAQs: Automating Training Request Approvals with AI in Microsoft Copilot Studio

• What is AI-driven approval in Microsoft Copilot Studio?
  AI-driven approval in Microsoft Copilot Studio automates the decision-making process for requests, such as employee training requests. Instead of waiting for human manager approval, AI evaluates the request based on predefined rules and updates the approval status automatically in Dataverse.
• How does the training request approval system work?
  The system works in a few steps:

1. An employee submits a training request in Dataverse.
2. The AI agent flow in Copilot Studio retrieves the request.
3. The AI evaluates the request against predefined approval criteria.
4. The AI updates the request status as Approved or Rejected.

• What are the prerequisites for setting up AI approval in Copilot Studio?
  To implement AI-based training approvals, you need:

1. Access to Microsoft Copilot Studio.
2. A Power Platform environment with Dataverse enabled.
3. Basic knowledge of Dataverse tables and Copilot Studio agent flows.

• Can AI completely replace human approval for training requests?
  Yes, AI can handle approval entirely if the evaluation logic is clearly defined. AI ensures faster, consistent, and scalable approvals, reducing administrative overhead. However, organizations can still add manual review stages if needed.

The post Automating Training Request Approvals Using AI in Microsoft Copilot Studio first appeared on Microsoft Dynamics 365 CRM Tips and Tricks.

Today’s businesses rarely operate within a single application. Applications such as Sales Hub, which manage leads, opportunities, accounts and revenue to help sales teams close deals faster. On the other hand, Customer Service helps handle cases, tickets and customer support interactions to deliver faster issue resolution. Field Service is used to schedule technicians, manage work orders and track on-site services efficiently. Marketing Automates campaigns, emails, and customer journeys to generate and nurture leads. Project Operations plans, tracks, and bills projects by combining project management, resources, and financials in one system.

Here, each application works well individually, but together they often feel disconnected. Users need to switch between platforms, copy information manually, and spend more time navigating systems than actually solving problems. Even with AI copilots available, the experience doesn’t always improve because most copilots are still limited to one application at a time.

Key Takeaways

• Traditional copilots are limited to single applications
• MCP Server enables structured, cross-system interactions
• Copilot agents can execute workflows across Business Central, Dataverse, and SharePoint
• Reduces manual effort and system switching significantly

Limitations of Traditional Copilots:

Traditional copilots are helpful assistants, but their scope is short. They can answer questions, summarize information or perform small actions within the app they belong to. However, they struggle when there are tasks that require answers from multiple systems.

As a result, users still do most of the work manually. The copilot informs but it doesn’t truly execute.

What is MCP Server in Copilot? (Simple Explanation)

MCP (Model Context Protocol) Server provides a structured way for copilots to interact with multiple systems using predefined tools instead of direct API calls.

Copilot with MCP Server:

To make Copilot genuinely useful, it needs accessibility across multiple systems. This is where Microsoft Copilot, combined with the Model Context Protocol (MCP) comes into the picture.

MCP Server acts as a bridge between Copilot agents and enterprise tools. Instead of directly accessing databases or API’s in an unstructured way, the agent communicates through standardized tools exposed by the MCP server. These tools define exactly what the copilot needs to do. Whether it’s retrieving data or updating records.

MCP Server with different Systems:

With MCP Server, the copilot can interact with different platforms such as Microsoft Dynamics 365 Business Central, Microsoft Dataverse and Microsoft SharePoint.

Instead of treating each system separately, the copilot works across them as if they were one connected environment. For the user, it feels like interacting with a single intelligent assistant.

Key Criteria to Consider While Setting Up MCP:

Before building an MCP-powered agent, start with –

• Creating a Copilot agent from scratch by attaching the right tools. Each tool represents a specific capability, such as reading customer data, updating records or accessing documents.
• Clear descriptions and proper instructions ensure the agent understands how and when to use each tool. Once activated, the copilot can securely communicate with multiple systems.

Steps to Implement Copilot with MCP Server

Let us understand this by 3 real-life scenarios –

Scenario 1: Sales Deal Closure with Dynamics 365 Business Central

In this scenario, the copilot agent will check customer financial information from Business Central before closing a sales deal. It helps verify details like credit limits or financial exposure, so the user can decide whether the deal can be approved or not.

Step 1: Let us start by creating a blank Copilot agent named ‘Enterprise Unified Agent’. At this stage, the agent has no knowledge or access to any systems.

Step 2: A tool needs to be added that allows the agent to connect with ‘Microsoft Dynamics 365 Business Central’ through the MCP server.

Step 3: Inside Business Central, the MCP Server Configuration needs to be opened in order to connect Copilot with it.

Standard API’s are then exposed as tools so the copilot can access them.

After saving the configuration and refreshing the tools, they become available for the agent to use.

Step 4: Each tool needs to be provided with a clear ‘Description’ explaining its purpose. These descriptions help the copilot understand when and how each tool should be used during interactions with the user.

Step 5: Add ‘Instructions’ in the agent, which provides guidelines to the copilot on how to respond, what tasks to perform, and how to use the available tools during interactions. Once the configuration is complete, the agent can start interacting directly with Business Central data.

Step 6: Now the user needs to simply ask a question regarding sales deal closure, and the copilot retrieves the required information, such as customer details, along with the final decision as ‘Approved’ or ‘Not Approved’, without the need to manually navigate through the system.

Scenario 2: Technician Scheduling and Service Booking with Business Central and Microsoft Dataverse Server

In this scenario, the copilot helps manage service requests by checking asset details, verifying spare parts availability, and scheduling a technician. It collects issue details, date, and time, then books the service by using information from both Business Central and Dataverse.

Now we have to enhance the copilot by connecting it to multiple systems instead of just one.

Step 1: The second tool for ‘Microsoft Dynamics 365 Business Central’ needs to be configured using the same MCP setup process. This allows the agent to access additional data and perform more actions within the system.

Add ‘Description’ for the tool as per the requirement:

Step 2: An additional tool is needed to be added for ‘Microsoft Dataverse’ so the agent can retrieve records that are stored in it.

Add ‘Description’ for the tool as per the requirement:

Step 3: Add ‘Instructions’ to the agent as per the requirement:

Step 4: Now we need to make a connection between ‘Microsoft Business Central’ and ‘Microsoft Dataverse’ by entering the environment URL and enabling the data synchronization so the copilot can access updated information from both systems.

Step 5: Now we need to add Dataverse tables as knowledge sources, which will allow the Copilot to retrieve data from them whenever needed.

Necessary Tables are added as below:

Step 6: Now the user asks a question regarding ‘Technician booking’, so the copilot retrieves the required information by using both Microsoft Dataverse and Microsoft Dynamics 365 Business Central to process the request and provide the response.

Step 7: The agent interacts with the user to collect required details such as:

• Issue description
• Service date and time

As you can see above, the copilot asks for the required details like the ‘Issue & service time’, then checks the system and schedules the technician accordingly

Scenario 3: Retrieve Instructions from Documents with SharePoint

In this scenario, the copilot accesses documents stored in SharePoint to answer user questions. It reads policies, guidelines, or reference files and provides the required instructions so users can quickly find the information they need.

Step 1: To retrieve instructions, documents need to be added to Microsoft SharePoint.

Step 2: To make these documents accessible, Microsoft SharePoint needs to be added as a knowledge source for the Copilot, as shown below

We need to upload the necessary ‘Documents’ to Microsoft SharePoint as below

Step 3: ‘Descriptions’ and ‘Instructions’ need to be added to guide the agent on how and when it should use the document-based information during conversations.

Step 4: Now the user needs to ask the agent questions that require information from documents in SharePoint.

As you can see above, the copilot searches the documents and shows the required instructions step by step based on the question.

Conclusion:

By the end of these 3 scenarios, the copilot grows from a simple blank agent into a smart assistant that can connect to different systems and help complete tasks. Instead of opening multiple apps like Business Central, Dataverse, or SharePoint, users can just ask the copilot and get the information they need in one conversation. This shows how a basic copilot can gradually become a powerful tool that not only answers questions but also helps get real work done faster.

FAQs

1. What is MCP Server in Microsoft Copilot?

MCP (Model Context Protocol) Server enables Copilot to interact with multiple systems using predefined tools instead of direct API calls. It standardizes how Copilot accesses and executes actions across platforms.

2. Can Copilot work across multiple Dynamics 365 applications?

Yes. With MCP Server, Copilot can interact with Business Central, Dataverse, and SharePoint within a single workflow, enabling cross-system execution.

3. How is MCP different from traditional API integrations?

APIs require custom integration logic, while MCP exposes standardized tools with predefined schemas, making it easier for Copilot to discover and use capabilities dynamically.

4. What are MCP tools in Copilot?

MCP tools are predefined actions (like retrieving data or updating records) that Copilot can invoke. Each tool represents a specific business capability exposed by a system.

5. Is MCP Server required for building advanced Copilot agents?

For cross-system and action-oriented Copilot scenarios, MCP Server is essential as it enables structured, secure, and scalable integrations.

The post How to Build a Cross-System Copilot Agent in Dynamics 365 Using MCP Server first appeared on Microsoft Dynamics 365 CRM Tips and Tricks.

Automation testing requires interacting with different UI elements in an application. Tests may fail for several reasons such as incorrect selectors, synchronization issues, or unexpected changes in the UI. Identifying reliable UI selectors is therefore crucial when writing complex automation scripts. One of the most common causes of UI automation failures is the use of incorrect or unstable selectors.

Some common reasons why automation scripts fail include:

Targeting Incorrect Selectors

• The UI element no longer exists on the page.
• The selector matches multiple UI elements.
• The UI structure has changed after application updates.

Timing and Synchronization Issues

• Modern web applications often load content asynchronously. As a result, UI elements may appear after a delay. Tests can fail if the script attempts to interact with an element before it is available. Using proper waiting mechanisms such as explicit waits and assertions helps ensure that elements are present and in the correct state before interacting with them.

Playwright Inspector

Debugging tools such as the Playwright Inspector allow to pause test execution and visually inspect the web page during test runs. This makes it easier to identify locator issues and understand how the test interacts with the application.

The Playwright Inspector works as a debugging interface that opens when Playwright tests are executed in debug mode. It provides several useful capabilities:

• Pause and step through test execution
• Inspect elements on the page
• Validate selectors used in the test
• Generate reliable locators
• Observe browser actions in real time

Because Playwright interacts with a real browser, it allows to observe actual browser behavior. This helps in verifying that the application performs as expected during automation. With the Inspector, you can:

• Watch the browser perform each action
• Verify navigation, clicks, and form submissions
• Confirm that the application behaves as expected
• Step through the test line by line
• Ensure waits and assertions are placed correctly

In previous blog we have already explored how Playwright can be used for Dynamics 365 automation testing wherein we have simply created contact record using Typescript code.

Using TypeScript with Complex Selectors:

Let’s extend the same use case. While creating a Contact record in Dynamics 365 CRM, we will now work with more complex UI elements such as lookup fields and option set fields. At the same time, we will use the Playwright Inspector for live debugging.

To perform the debugging process you can add a page.pause() method to your test. This way you will see the GUI page appears for “Playwright Inspector” while running the test.

By following the same steps provided in previous blog you can complete the Playwright setup (if not already) and here is the upgraded version of typescript code with more complex selectors and debugging step.

Typescript:

Create tests/contact.spec.ts:

Note: You can refer below code await page.pause () is added explicitly.

import { test, expect, Page } from '@playwright/test';

import { populate } from 'dotenv';

import fs from 'fs';

import path from 'path';

 

// --- AUTOMATIC VIDEO SAVER (FIXED) ---

test.afterEach(async ({ page }, testInfo) => {

const video = page.video(); // get video BEFORE closing

await page.close();

 

if (video) {

const videoPath = await video.path();

const timestamp = new Date().toISOString().replace(/[:.]/g, '-');

const newName = `${testInfo.title.replace(/\s+/g, '_')}_${timestamp}.webm`;

const historyFolder = 'video-history';

 

if (!fs.existsSync(historyFolder)) {

fs.mkdirSync(historyFolder);

}

 

const newPath = path.join(historyFolder, newName);

await fs.promises.copyFile(videoPath, newPath);

 

console.log(` Video saved to: ${newPath}`);

}

});

 

test('Create New Contact in D365', async ({ page }) => {

// Debugging step

await page.pause()

test.setTimeout(120000);

 

const appId = process.env.APP_ID!;

const orgUrl = process.env.CRM_URL!;

 

// 1. Navigate directly to Contacts grid, pause command use for debugging

 

await page.goto(`${orgUrl}/main.aspx?appid=${appId}&pagetype=entitylist&etn=contact`);

await page.waitForLoadState('domcontentloaded');

 

// 2. Click New (robust selector)

const newButton = page.locator("(//span[contains(.,'New')])[1]");

await expect(newButton).toBeVisible({ timeout: 30000 });

await newButton.click();

 

// 3. Wait for form to load (First Name field)

const firstName = page.locator('[data-id*="firstname"] input');

await expect(firstName).toBeVisible({ timeout: 30000 });

 

// 4. Fill mandatory fields

await firstName.fill('Test');

await page.locator('[data-id*="lastname"] input').fill('Bot');

await page.locator('[data-id*="jobtitle"] input').fill('Dev');

await page

.locator('[data-id*="emailaddress1"] input')

.fill('auto34@example.com');

 

const parentAccountInput = page.locator('[data-id*="parentcustomerid"] input');

 

// A. Click the field to activate it

await parentAccountInput.click();

 

// B. Type the search value

await parentAccountInput.fill('test');

 

// C. Wait for the dropdown results to appear and click the correct one

// We look for a list item (role=option or li) containing the text 'test'

const lookupResult = page.getByRole('option', { name: /test/i }).first();

 

// Ensure the result is actually visible before clicking to avoid flakes

const resultList = page.locator('ul[aria-label*="Lookup results"]');

await resultList.waitFor({ state: 'visible', timeout: 10000 });

 

// 4. Select the item from within that list

// We use locator('li') to match the list item specifically, ensuring we don't click other UI elements

const correctOption = resultList.locator('li').filter({ hasText: /test/i }).first();

 

await correctOption.waitFor({ state: 'visible', timeout: 5000 });

await correctOption.click();

 

// 5. Validation (Optional but recommended)

// Ensure the input field now contains the text (meaning selection stuck)

//await expect(parentAccountInput).toHaveValue(/test/i);

 

// --- PREFERRED METHOD OF CONTACT FIX ---

 

// 1. Target the wrapper, NOT the input (which is invisible)

// We use .first() just in case the selector matches the label and the field

const contactMethodDropdown = page.locator('[data-id*="preferredcontactmethodcode"]').first();

 

// 2. Wait for the wrapper to be visible

await contactMethodDropdown.waitFor({ state: 'visible', timeout: 10000 });

 

// 3. Click to expand the list

await contactMethodDropdown.click();

 

// 4. Select 'Email' from the expanded list

const emailOption = page.getByRole('option', { name: 'Email' });

 

// Wait for the dropdown animation

await emailOption.waitFor({ state: 'visible', timeout: 5000 });

await emailOption.click();

 

// 5. Save (button role, not menuitem)

const saveButton = page.locator("(//span[contains(.,'Save')])[1]");

await expect(saveButton).toBeVisible({ timeout: 30000 });

await saveButton.click();

 

});

Run the test:

Run the above typescript file using below command

npx playwright test contact.spec.ts –headed

As you have add a page.pause() it run your tests in debug mode. You can play, pause or step through each action of your test using the toolbar at the top of the Inspector.

Step Over:

Clicking the “Step Over” button in the Playwright Inspector will run the test step by step and will show a LIVE execution on browser as shown:You can see the current action highlighted in the test code, and matching elements highlighted in the browser window.Pick Locator:

While debugging, you might need to choose a more resilient locator. You can do this by clicking on the Pick Locator button and hovering over any element in the browser window. While hovering over an element you will see the code needed to locate this element highlighted below which then you can copy it into your code.Record feature:

You can click on “Record” button and “Start Recording” the other web element with user interactions corresponding typescript code will be recorded/generated in background through recording feature.When started recording you will be able to locate the element start filling in data and can view generated code.The new Playwright Inspector window opens up where the recording code can be viewed and can be copied in the existing code.You can explore more about Playwright locators here and may need to tweak little bit in recorded script and start using the same in existing code.

Conclusion:

Using Playwright Inspector makes debugging UI automation much easier by allowing inspect elements and execute tests step by step. This helps identify unstable selectors and improves the reliability of automation scripts. This leads to more stable tests and a smoother automation development process.

FAQs

What are the common causes of UI automation test failures in Microsoft Dynamics 365?

UI automation tests in Microsoft Dynamics 365 commonly fail due to:

• Unstable or incorrect UI selectors
• Frequent UI updates in Dynamics 365
• Asynchronous loading of elements
• Timing and synchronization issues
  Using reliable locators and proper wait strategies helps reduce failures.

What is UI automation testing in Microsoft Dynamics 365 CRM?

UI automation testing in Microsoft Dynamics 365 involves simulating user interactions (like form entry, navigation, and record creation) to validate that the CRM application behaves correctly. Tools like Playwright help automate these workflows efficiently.

How does Playwright help with Dynamics 365 automation testing?

Playwright enables:

• Cross-browser automation
• Reliable element handling with auto-waiting
• Powerful locator strategies
• Built-in debugging tools like Playwright Inspector

This makes it highly effective for automating complex Dynamics 365 applications.

Is it possible to automate end-to-end workflows in Microsoft Dynamics 365 using Playwright?

Yes, Playwright supports full end-to-end automation in Dynamics 365, including navigation, form submissions, lookups, and validations. With proper waits and selectors, entire business workflows can be reliably automated.

How can you verify form submission in Dynamics 365 automation?

Form submission can be verified by checking confirmation messages, updated field values, or successful navigation. Assertions ensure that the action has completed as expected.

How do you handle timing issues in Dynamics 365 automation?

Timing issues are handled using Playwright’s auto-waiting along with explicit waits like waitFor() and assertions. This ensures elements are fully loaded and ready before interaction, reducing test failures.

What is the advantage of using role-based selectors in Playwright?

Role-based selectors improve reliability by targeting elements based on accessibility roles rather than structure. This makes tests more stable, especially in dynamic applications like Dynamics 365.

The post How to Use Playwright Inspector for Faster Test Debugging in Dynamics 365 CRM first appeared on Microsoft Dynamics 365 CRM Tips and Tricks.