Traditionally, creating a Dataverse solution involves manually creating tables, columns, relationships, and sample records through the Power Apps maker portal or by writing scripts and using Power Platform CLI.

With Dataverse skills for coding agents, we can describe our requirements in natural language and let the coding agent implement them directly in the connected Dataverse environment.

In this blog, I will demonstrate this capability by building a Recruitment Management solution using a coding agent.

The objective is to create the required Dataverse tables, establish relationships, add realistic sample data, and verify that everything has been provisioned successfully in the connected environment.

Use Case: Recruitment Management

For this demonstration, we are building a simple Recruitment Management solution that takes a few tables like jobs, interviews, etc.

Prerequisites

Before starting the implementation, I had the following prerequisites:

1. GitHub Copilot/coding agent
2. Power Platform CLI
3. Dataverse skills configured for the coding agent

GitHub Copilot Installation

The first step is to install and configure GitHub Copilot in your development environment.

After installation, verify that Copilot is available in your development environment and that you can interact with the coding agent.

Step 1: Connect to the Dataverse Environment

The first step is to authenticate the coding agent with the target Microsoft Dataverse environment. This establishes the connection required for the agent to discover and work with Dataverse resources.

Using Power Platform CLI, authenticate against your Dataverse environment with the following command:

pac auth create –url https://<your-org>.crm.dynamics.com

Replace <your-org> with the URL of your Dataverse environment.

Once authentication is complete, verify the available authentication profiles:

pac auth list

With the Dataverse environment connected, the coding agent can work with the environment to create and manage solutions, tables, relationships, and data as part of the implementation.

Step 2: Add Dataverse Skills

Once the Dataverse environment is connected, the next step is to add the Dataverse skills to the coding agent.

Dataverse skills provide the agent with the knowledge and capabilities required to understand Dataverse concepts and perform common development tasks, such as creating solutions, tables, columns, relationships, and data.

In the coding-agent terminal, add the Dataverse skills using:

/plugin marketplace add dataverse

After the Dataverse skills are added, the coding agent can use them when working with the connected Dataverse environment.

The key benefit is that developers don’t need to manually provide every Power Platform CLI command, tool parameter, or implementation detail. Instead, we can describe the desired outcome in natural language, and the coding agent can orchestrate the required Dataverse operations.

This also reduces context switching between documentation, CLI commands, scripts, and the Dataverse UI, allowing the development workflow to remain within the coding-agent experience.

Step 3: Give the Prompt to the AI Agent

Now comes the implementation part.

Instead of manually creating five tables and their relationships, we can describe the solution we want using natural language.

The agent interprets the requirements and determines the Dataverse components that need to be created.

At this point, we don’t have to manually specify every CLI command or create each table from the Power Apps maker portal.

Step 4: Approving Changes

As the agent performs operations against the environment, it may ask for approval before executing certain actions.

For example, the agent may request approval to:

1. Create or modify Dataverse components
2. Execute Power Platform CLI commands
3. Run generated scripts
4. Load data into the environment

Review the proposed action and approve it when you are comfortable with the changes.

This approval step is particularly important when working with development or shared environments because the coding agent is capable of making actual changes to Dataverse resources.

Output

After the agent completes the requested operations, we can verify the solution in Dataverse.

The Recruiting solution should now contain the requested tables and relationships.

We can also inspect the tables and their relationships to verify that the requested data model was created successfully. The agent can then query the newly created data and answer business questions.

Conclusion

The introduction of Dataverse skills for coding agents provides a new way to build and manage Dataverse solutions using natural language. We use a coding agent to create the required tables, relationships, sample records, and verify the resulting components directly in the connected Dataverse environment.

FAQs

What are Dataverse skills for coding agents?
Dataverse skills are capabilities added to a coding agent such as GitHub Copilot that give it the knowledge to understand Dataverse concepts and perform development tasks like creating tables, columns, relationships, and data, all from natural language instructions.

Do I need to know Power Platform CLI to use this?
Basic familiarity helps for the initial setup and authentication steps, but once Dataverse skills are configured, you interact with the agent in natural language rather than writing CLI commands manually.

Is it safe to use a coding agent in a live Dataverse environment?
The agent includes an approval step before executing actions that affect Dataverse resources. It is still recommended to test in a development or sandbox environment before working with production data.

What kinds of Dataverse operations can the coding agent perform?
The agent can create and manage solutions, tables, columns, relationships, and sample data. It can also query the environment and answer business questions based on the data model it has built.

Can the coding agent replace a Dataverse developer entirely?
Not entirely, but it significantly reduces the time and effort required for common development tasks. Developers still need to review, approve, and validate the agent’s output to ensure it meets business requirements.

Does this work with any Dataverse environment?
Yes, as long as the environment is accessible via Power Platform CLI and the coding agent is authenticated against it using the standard pac auth create command.

What happens if the agent makes a mistake?
Because the agent requests approval before executing changes, you have the opportunity to review and reject any action that does not look right before it affects your environment.

The post Build Dataverse Solutions Faster with a Coding Agent in Dynamics 365 first appeared on Microsoft Dynamics 365 CRM Tips and Tricks.

In a retail e-commerce company, the team was building an AI customer support agent to handle common queries like order status, returns, refunds, and product information. In the beginning, the prompt was tested manually with a few sample questions, and everything seemed to work fine.

However, end users don’t type like QA testers. They use shortcuts, mix multiple questions into one sentence, include slang when frustrated, and often skip punctuation. A prompt that worked well in controlled testing started missing the intent in real scenarios, giving responses that felt robotic or incorrect. Instead of reducing support workload, this led to more confusion and increased escalations to human agents.

One of the biggest challenges was inconsistency in responses. Customers would ask similar questions in different ways, such as “Where is my order?” “Track my shipment”, or “Can you tell me my delivery status?”, but the agent would sometimes return different or inaccurate answers. In some cases, it failed to recognize the intent entirely and responded irrelevantly, which frustrated users.

Another issue was the unpredictability of user inputs. Real users often type informally, make typos, or use incomplete sentences. While the agent performed well with structured test queries, it struggled with these real-world variations. This gap between controlled testing and actual usage became very noticeable.

Scalability challenges in testing also emerged. Manually validating every variation of a question was time-consuming and inefficient. As the number of supported scenarios increased, it became nearly impossible to test everything, leading to gaps that only surfaced in production. To address this, batch testing for prompts was introduced. Real customer queries were collected from past chat logs and support tickets, including variations, unclear queries, and edge cases. Instead of testing individually, these were run in bulk and the responses analysed.

Key Takeaways

• Manual testing doesn’t reflect real usage – controlled test questions rarely capture how end users actually type (typos, slang, mixed intents, no punctuation).
• Inconsistent responses to similar questions are a major sign a prompt needs batch validation, not just spot-checking.
• Scalability is the real bottleneck – as supported scenarios grow, manual testing becomes impractical and gaps only surface after going live.
• Batch testing uses real data – pulling actual queries from chat logs and support tickets surfaces edge cases that hand-written test questions miss.

This approach helped quickly identify where the agent was failing, whether in understanding intent, selecting the correct response, or handling variations. Based on these insights, the prompts were refined, intent handling was improved, and responses became more consistent. After these improvements, the agent started delivering more accurate and reliable answers. It also reduced manual testing effort and made it easier to validate future updates. Overall, this approach helped build a more stable and user-friendly experience that better aligned with real customer behaviour.

Step-by-Step: Enable & Use Batch Testing Prompts

Steps to define the Test Cases

1. Sign in to Copilot Studio , Power apps , Power automate any one of this so here we trying from copilot studio.
2. Create the Tool then with instructions add the prompt, you can see there are many simple ways to create prompt you can choose according to your business need. Shown in below screenshot.

3. In Copilot Studio, go to Tools and select your prompts.
4. Locate the prompt you want to test, then click on the three-dot menu or ellipses (…) next to it.
5. Now you can see, Test hub (Preview)
6. Below is an example screenshot view of how the Tools section visible in Copilot Studio.

When you click on test hub in below screenshot you can see the view and options test hub provide for test cases.

Prepare Your Test Cases or test set

You can simply create a list of test cases or prompts

Example:

• Where is my order?
• Track my shipment
• Order status please
• I didn’t receive my package
• Refund for my order
• wrong size shoes want to exchange but also track my watch

Include:

• Different variations of same question
• Real user queries from chat logs.
• Edge cases typos, short queries, unclear questions.

So, there are some ways to create the test cases like, Upload test case, generate test cases, use activity data and in below screenshot you can see the test cases which was manually written or added.

When you have done with your set of test cases then,

Run Batch Test

• Click Run to Execute all the test cases at once.
• System will process all prompts at once

Analyze Results

• You can see the result of each your test case
• Success / failure results
• Incorrect or irrelevant answers
• Wrong intent detection
• Missing responses
• Inconsistent answers

If your test cases are failing it will give detailed summary of search result (As shown in below screenshot) to you from that you can Improve Your Bot

Based on results:

• Rewrite, rephrase your prompts
• Improved your instructions, you can use prompt library which is inbuilt and AI summarized.
• Update knowledge sources in prompts.
• Also, you can easily add your missing scenarios after the run execute as well.

You can Re-Run again after changes Compare results → check there is any improvement or not.

Conclusion

Batch testing prompts in Microsoft Copilot Studio makes bot testing faster, smarter, and more reliable. Instead of checking a few queries manually, it allows us to validate real-world user scenarios at scale and quickly identify gaps in responses in a single click.

It helps ensure consistency, improves accuracy, and reduces the chances of unexpected behavior once the bot is live. Over time, it becomes an essential part of maintaining quality and continuously improving the chatbot experience, making it more dependable and aligned with real user needs.

FAQs

1. What is batch testing in Copilot Studio?
   Batch testing lets you run multiple test cases or prompts at once instead of validating them one at a time, so you can quickly see how your Copilot agent handles a wide range of real user queries.
2. Why isn’t manual prompt testing enough?
   Manual testing typically uses a small, controlled set of sample questions. Real users type differently, with typos, slang, mixed intents, and incomplete sentences, so a prompt that passes manual testing can still fail in production.
3. Where do test cases come from?
   Test cases can be manually written, uploaded, generated automatically, or pulled from real activity data such as past chat logs and support tickets.
4. What kind of issues does batch testing catch?
   It surfaces incorrect or irrelevant answers, wrong intent detection, missing responses, and inconsistent answers across similarly worded queries.

The post How Batch Testing Prompts Helps You Build Reliable Copilot Agents first appeared on Microsoft Dynamics 365 CRM Tips and Tricks.

When organizations move to Customer Insights – Journeys, one question often comes up immediately: what happens to the consent preferences we already have?

Your contacts and leads may already contain years of email preferences through fields such as Email and Bulk Email. Asking every existing customer to provide consent again is not only unnecessary, but it can also create friction and potentially leave you with incomplete consent data.

The challenge is that real-time journeys use a different consent model. They rely on contact point consent records linked to compliance profiles and purposes, rather than treating the legacy consent fields on contact or lead records as the source of truth.

This is where the Load Consent feature in Customer Insights – Journeys becomes useful.

Load Consent helps organizations migrate existing consent preferences from contacts, leads, or legacy subscription lists into the new consent framework in bulk. Instead of manually recreating consent records or launching another opt-in campaign, you can use the consent data you already have to establish a compliant foundation for your real-time journeys.

In this blog, we’ll look at how Load Consent works, what it reads from your existing records, and how you can use it to migrate consent data into Customer Insights – Journeys.

Why Existing Consent Data Must Be Migrated to Customer Insights – Journeys

Real-time journeys do not use the legacy Email and Bulk Email preference fields as their primary consent source by default. They rely on contact point consent records tied to compliance profiles and purposes. For more details on compliance and the consent center, refer to our previous Blog.

That is a fundamentally different model from the legacy Bulk Email flag, which used to act as a single source of truth on the contact record itself. If you skip the consent migration step, you risk creating a gap between your historical consent data and your new real-time journey configuration. Contacts may be unable to receive communications because no contact point consent records exist, while historical opt-outs may not be reflected correctly in the new consent model.

What Load Consent Actually Does

Suppose your organization is setting up real-time journeys for the first time and wants marketing emails to respect the Bulk Email preferences already recorded on your contacts, rather than starting consent collection from zero.

At a high level, Load Consent reads existing consent signals from contacts or leads and converts them into contact point consent records against a compliance profile and purpose you choose. It’s a one-time (or repeatable) bulk operation, not a live sync, so it’s a migration tool, not an ongoing integration.

A few mechanics worth understanding before you run it:

• It only pulls from the single email field configured in your audience settings, not every email field on the record. For more details, you can refer to this doc.
• It evaluates both the Bulk Email and Email flags together. Either one set to “Do Not Allow” is enough to opt the contact point out.
• When multiple contacts or leads share the same email address, the tool won’t opt that address in unless every linked record agrees: one holdout sets the whole address to opted out.
• It can also generate tracking consent records from the contact’s tracking preference (leads don’t carry a tracking field, so this only applies to contacts).

Prerequisites

Before running Load Consent, make sure the following are in place:

Access & permissions

• Read access to contact and lead records
• Create and update permissions on contact point consent records

Setup

• A compliance profile with the purposes already created, since Load Consent needs somewhere to write the records to
• The audience configuration email field correctly set, since this determines which email address gets loaded
• If you operate across multiple business units, a plan to run Load Consent separately for each business unit/compliance profile combination

A quick note on the “Do Not Allow” dropdown fields: both contacts and leads carry two separate two-value fields that Load Consent reads directly, Do Not Allow Emails (schema name: donotemail) and Do Not Allow Bulk Emails (schema name: donotbulkemail). Each one is a simple option set of Allow or Do Not Allow, with no in-between “not set” state, which is exactly why a single field flipped to Do Not Allow is enough to opt a contact point out when the load runs.

How to Load Consent:  Navigate to the Consent Center. Go to Customer Insights – Journeys > Audience > Consent Center.

Click the Load consent button from the ribbon bar as below:

Choose your source: Decide whether you’re loading from contacts, leads, or a legacy subscription list. In this blog, let us use contacts as the consent source.

Note: You’ll also see Subscription list as a selectable source alongside contacts and leads. That’s because subscription lists were how the legacy Outbound Marketing app tracked consent. Since Outbound Marketing is being retired, Load Consent lets you pull that legacy list data directly into Customer Insights – Journeys.

Select the destination compliance profile and purpose. Pick the compliance profile you want the consent records created under (usually a profile that already has a preference center attached) and the specific purpose. Here we will be using the preexisting Default Compliance profile

Map the fields: Confirm which purpose reflects Bulk Email (commercial communications) and which reflects Email (transactional).

A quick note on the “Do Not Allow” dropdown fields: both contacts and leads carry two separate two-value fields that Load Consent reads directly, Do Not Allow Emails (schema name donotemail) and Do Not Allow Bulk Emails (schema name donotbulkemail). Each one is a simple option set of Allow or Do Not Allow, with no in-between “not set” state, which is exactly why a single field flipped to Do Not Allow is enough to opt a contact point out when the load runs.

Run the load: The system evaluates each record against the rules above and creates or updates the corresponding contact point consent records.

Verify the results: Spot-check a sample of contacts, particularly ones with duplicate records sharing an email address, to confirm the resulting consent status matches what you expect. The bulk contact point consent records were loaded as shown below:

Before using this feature directly on production, consider the Do and Don’t mentioned below:

Do:

• Export your existing consent data to Excel before running any data restore. A restore reverts consent records to their backup-time state, and you’ll want a reference copy
• Double-check which purpose you’re mapping Bulk Email vs. Email into: typically, Commercial and Transactional respectively, but confirm against your own compliance profile naming
• Run a small test batch first if you have a large volume of duplicate email addresses, so you can validate the opted-in/opted-out outcome before committing broadly

Don’t:

• Don’t expect Load Consent to pick up consent stored in a custom field. If your organization tracks consent somewhere other than Allow Bulk Email, you’ll need Import from Excel instead. Audience configuration won’t help here either. It only lets you choose which email address field is read, not which consent field is read, so a custom consent field is invisible to Load Consent regardless of how audience configuration is set up.
• Don’t treat this as a live sync. It won’t automatically pick up future changes to contact or lead fields
• Don’t assume it applies to any data source beyond contacts, leads, and legacy subscription lists. There’s no support for pulling consent from anywhere else, and subscription lists are a legacy Outbound Marketing concept: you can’t create new ones in real-time journeys, only migrate the ones you already have

Conclusion

Migrating to Customer Insights – Journeys does not mean you have to rebuild your consent data from scratch.

The Load Consent feature helps organizations bring existing consent preferences from contacts, leads, and legacy subscription lists into the contact point consent model used by real-time journeys. This allows you to preserve historical opt-ins and opt-outs while establishing the compliance structure required for future communications.

However, Load Consent should be treated as a data migration process, not an ongoing synchronization mechanism. Before running it in production, make sure your compliance profiles, purposes, audience configuration, and consent preferences are correctly configured. Testing with a smaller data set can also help identify issues involving shared email addresses or incorrect consent mappings.

Once the consent data has been successfully loaded and verified, your organization can begin using Customer Insights – Journeys with a stronger and more reliable compliance foundation.

The key takeaway is simple: your existing consent history still has value. Load Consent helps you carry that history forward instead of asking your customers to start over.

Frequently Asked Questions

1. What is the Load Consent feature in Customer Insights – Journeys?

Load Consent is a built-in feature in Customer Insights – Journeys that helps migrate existing consent preferences from contacts, leads, or legacy subscription lists into contact point consent records. These records can then be used with compliance profiles and purposes in real-time journeys.

2. Does Load Consent automatically synchronize future consent changes?

No. Load Consent is a bulk migration process and not a live synchronization feature. If consent preferences change on a contact or lead record after the load has been completed, those changes are not automatically reflected in the contact point consent records.

3. Which consent fields does Load Consent use?

For contacts and leads, Load Consent evaluates the legacy Do Not Allow Email and Do Not Allow Bulk Email preferences. The configured audience email field determines which email address is used when creating the contact point consent records.

4. Can Load Consent migrate consent stored in custom fields?

No. Load Consent does not read consent values from custom consent fields. If your organization stores consent information in custom fields or another external data source, you may need to use an alternative approach, such as importing consent data from Excel.

5. What happens when multiple contacts have the same email address?

When multiple records share the same email address, Load Consent evaluates the consent status associated with that shared contact point. If one of the linked records indicates that email communication is not allowed, the resulting consent outcome can affect the shared email address.

6. Can Load Consent be used for leads as well as contacts?

Yes. Load Consent supports contacts and leads as consent sources. It can also be used to migrate consent information from legacy subscription lists created for Outbound Marketing.

7. Do I need a compliance profile before running Load Consent?

Yes. You should have the required compliance profile and purposes configured before running Load Consent because the feature needs a destination for the contact point consent records it creates or updates.

8. Should I test Load Consent before running it in production?

Yes. It is recommended to test the process with a smaller data set first, especially if your environment contains duplicate records or multiple contacts sharing the same email address. This helps verify that the resulting consent records match your expected outcomes.

The post Your Existing Consent Data Shouldn’t Have to Start From Zero first appeared on Microsoft Dynamics 365 CRM Tips and Tricks.

As organizations increasingly adopt Microsoft Power Platform, managing hundreds of apps, flows, agents, environments, and connectors can become challenging. Administrators need a simple way to understand what resources exist, who owns them, which environments they belong to, and what connectors they depend on.

To address this challenge, Microsoft provides Power Platform Inventory in the Power Platform admin center. It offers a centralized view of Power Platform resources and helps administrators search, filter, analyze, and manage resources across the organization.

What is Power Platform Inventory?

Power Platform Inventory provides administrators with a centralized inventory of Power Platform resources, including:

• Power Apps
• Power Automate cloud flows and agent flows
• Copilot Studio agents
• Environments and environment groups
• Connectors and connector operations

Administrators can access it from Power Platform admin center → Manage → Inventory. Microsoft also provides programmatic access through the Power Platform for Admins V2 connector, Power Platform APIs, and Azure Resource Graph.

Customize the Inventory with Add or Remove Columns

One useful capability in the Inventory experience is Add or remove columns.

Administrators can customize the inventory grid by selecting the information they need for a particular task. For example, when investigating connector dependencies, administrators can add the Connectors column to identify resources using specific connectors.

This makes it easier to focus on relevant information without displaying unnecessary columns.

 After selecting the required columns, the inventory grid displays the customized view.

This flexibility can be especially useful during governance reviews, security assessments, and dependency analysis. 

View Resource Details

Administrators can select a resource from the inventory to view more detailed information.

The resource details provide information through areas such as:

• Overview
• Connectors
• Usage

This allows administrators to move from a high-level inventory view to detailed information about a specific app, flow, or agent

Why is Power Platform Inventory Useful?

Power Platform Inventory can help organizations with several common administration and governance activities, including:

• Understanding the organization’s Power Platform footprint
• Identifying resource owners
• Investigating connector usage
• Supporting DLP and security reviews
• Identifying resources affected by connector changes
• Supporting licensing analysis
• Troubleshooting apps and flows
• Exporting inventory information for reporting and audits

The connector inventory capability is currently available in Preview and provides dependency information for supported Power Platform resources.

Business Use Case: Managing Connector Retirement

Consider an organization that uses Power Platform extensively across different departments. Over time, multiple Power Apps, Power Automate flows, and agents have been created using a particular connector.

Now, that connector is scheduled for retirement.

The IT team needs to determine:

Which Power Platform resources are using this connector, and which business processes could be affected?

Without centralized visibility, administrators may have to investigate individual apps and flows manually. Power Platform Inventory can simplify this process.

Step 1: Identify Affected Resources

The administrator reviews the Connectors information in the inventory and identifies the apps, flows, and agents that use the connector.

For example, the organization may discover that a customer approval app, an invoice processing flow, and a service notification flow all depend on the retiring connector.

Step 2: Assess Business Impact

The IT team can then work with the respective resource owners to understand the importance of each solution.

For example, if the invoice processing flow is responsible for automating a critical finance process, it should receive a higher priority for remediation.

Step 3: Plan Remediation

Once the affected resources have been identified and prioritized, the organization can plan to migrate them to a replacement connector, API, or another supported integration method.

The overall process becomes:

Identify → Assess → Remediate → Validate

This proactive approach can help reduce unexpected automation failures and maintain business continuity when connectors are retired or changed.

Export and Automate Inventory Data

Administrators can also export inventory information to CSV for governance reports, audits, and further analysis.

For organizations that want to automate governance activities, inventory data can be accessed programmatically using:

• Power Platform for Admins V2 connector
• Power Platform API
• Azure Resource Graph

This enables organizations to build custom reports and automated governance processes around their Power Platform environment.

Conclusion

Power Platform Inventory provides organizations with a centralized view of apps, flows, agents, environments, and connectors. It simplifies resource management, governance, and dependency analysis, especially when connectors are retired or changed. By identifying affected resources early, organizations can prioritize remediation and reduce business disruption.

FAQs

What is Power Platform Inventory?
Power Platform Inventory provides a centralized view of apps, flows, agents, environments, and connectors across an organization.

Where can administrators access Power Platform Inventory?
It is available in the Power Platform admin center under Manage → Inventory.

How does Power Platform Inventory support governance?
It helps administrators identify resource owners, review connector usage, analyze dependencies, and support security and compliance activities.

Can Power Platform Inventory help when a connector is retired?
Yes. Administrators can identify affected apps, flows, and agents and plan remediation before business processes are disrupted.

Can Power Platform Inventory data be exported or automated?
Yes. Inventory data can be exported to CSV and accessed programmatically for reporting and automated governance processes.

The post Power Platform Inventory: Simplify Power Platform Governance and Resource Management first appeared on Microsoft Dynamics 365 CRM Tips and Tricks.

Managing a full-capacity event can get tricky when cancellations leave seats open and new registrants have nowhere to go. Dynamics 365 Customer Insights – Journeys simplifies this with its native event waitlist capability, allowing marketers to manage capacity, queue new registrants, and automatically fill available seats. This blog walks through how to set up and manage a waitlist for a single-session webinar.

Why It Matters

Marketing events are judged on turnout, and turnout is judged against capacity. A webinar platform license, a guest speaker’s time, or a virtual room’s bandwidth all have a ceiling — and every empty seat at that ceiling is wasted spend. Before this feature, closing a full registration list meant either turning latecomers away entirely or manually chasing down replacements every time someone cancelled, usually in a spreadsheet parked outside the CRM. Which is a real pain for the Marketing Team.

Waitlisting solves this in two ways. First, it keeps demand visible instead of discarding it — everyone who wanted in after capacity was reached becomes a tracked, Waitlist record created rather than a bounce. Second, it automates the backfill, so a cancellation on Tuesday can be replaced with a confirmed registrant by Wednesday without an event coordinator manually working the list.

What the Feature Does

At its core, the feature lets you attach a maximum capacity to an event (and, separately, to individual sessions within an event). Once the capacity reached, further registrations are waitlisted. Which can be managed and maintained in any of 2 ways:

• Automatic backfill: when a spot opens up, the system finds the longest-waiting waitlisted contact and registers them immediately.
• Manual backfill: when a spot opens up, the contact is flagged as eligible, and you decide when and how to invite them to claim the seat.

How to Set It Up: A Single-Session Webinar

For a webinar, there’s no session-level agenda to worry about — capacity and waitlisting are configured once, directly on the event.

1. In the Customer Insights Journeys app > under Event Planning > Open the Event work area and go to Events > Open your webinar event (As I am setting it up, its publish status = Draft initially, and when done with set up, we can make it Live).
2. On the General tab, under the Capacity area. Set the maximum event capacity to the number of attendees your webinar platform can support.

3. Set the Waitlist for this event to Yes by changing the toggle “Enable waitlist” = yes
4. Once toggle is set to Yes, the “Auto-register waitlisted contacts” field gets visible, which is set to No by default.

Depending on the “Auto-register waitlisted contacts” setting on the event, the Auto-register waitlisted contacts behave as follows:

• If it’s set to Yes, the system generates a registration for that contact automatically and flips their status reason to Registered.

With auto-register turned on, there’s no manual step at all — the system changes the status reason from Waitlisted to Registered on its own the moment a seat frees up.

• If it’s set to No, the contact isn’t registered automatically. Instead, they need to be invited to confirm they still want the seat, typically via a segment and journey that targets people whose registration is waitlisted and flagged as invited.

Unlike the above option, someone must manually change their status reason from ‘Waitlisted’ to ‘Registered’ using the segment or journey automation.

Let’s keep the “Auto-register waitlisted contacts” toggle to yes as below:

Once setup is finished, clicking on the Go Live button publishes the event and makes it available to registrants.

Once the event is live, the auto-generated Event URL can be dropped into an email and distributed through a customer journey to a targeted segment for registration.

The event registration form that I have created and sent for registration is as follows:

When the user clicks on the “Register Now” button, the “Event Registration” record will be created automatically.

You can refer to the MS doc for more details about Marketing forms. Let’s now look at the Journey side, which triggers are available.

In Customer Insights – Journey app > under Real-time journeys > Journeys> create a new Journey record:

The available triggers are as follows:

The two waitlist triggers

Two journey triggers ship with the feature, and they cover the two moments in the waitlist lifecycle you’re most likely to want to message around:

• Marketing event registration created — fires when a new waitlist registration is created, useful for an immediate “you’re on the list” confirmation.
• Marketing registration created from waitlist — fires when a registration’s status reason flips from Waitlisted to Registered, useful for the “a seat opened up — you’re confirmed” moment

Select the appropriate trigger and choose your event record as below:

For this blog, let’s keep the Journey very simple. When the Event Registration record is created, the Registration confirmation email should be sent. In reality, it can be complex with follow-up steps, and you can use the custom trigger when the status reason of the event registration record is updated. You can refer to the MS doc for more details about the custom trigger.

How It Works

The mechanics are simpler than they might sound, and they hinge entirely on the status reason attached to each event registration record.

Every registration that comes in after capacity is reached is saved with a status reason of Waitlisted, rather than Registered.

In our example, when the 11^th attendee (as the capacity is set as 10) tries to register for the webinar, they will experience the waitlist form instead of the simple registration. Now they will click on the “Join a waitlist” button as displayed below:

Event registration record still created with status reason as Waitlisted, shown below:

When an existing registrant cancels (freeing up a seat), the system revisits the waitlist and identifies the oldest record — the contact who has been waiting longest, based on registration date and time.

As the “Auto-register waitlisted contacts” setting is set to Yes in our scenario, the system will auto-change the “Waitlisted” status reason to “Registered” — no manual step is required.

The status reason field is really the backbone of the whole feature — it’s what a segment or a journey trigger reads to know whether someone is holding a confirmed seat or still in the queue.

You can select a particular “Event Registration” record and can cancel the registration manually if needed, the 2 buttons available on selection of the record are Check in and Cancel Registration as shown below:

You will observe the warning on the event record itself that the event has reached its maximum registration capacity. For more details, refer to the MS doc.

With waitlisting configured for this webinar, here’s what happens end-to-end:

• Maximum event capacity is set to 10, Waitlist this event is set to Yes, and Auto-register waitlisted contacts is set to Yes.
• The Marketing event registration created trigger fires the moment someone lands on the waitlist, so they can immediately receive a “you’re on the waitlist, we’ll notify you if a slot opens” email rather than being left wondering through Journey.
• The Marketing registration created from the waitlist trigger fires the moment they’re promoted, sending a follow-up confirmation with the standard join link and calendar invite through Journey.

Conclusion

With event waitlisting, Customer Insights Journeys can automatically manage registrations as seats become available, while journey triggers keep registrants informed at each stage.

Looking to extend your Dynamics 365 capabilities? Explore Inogic for more Dynamics 365 solutions.

Have questions? Email us at crm@inogic.com

FAQs

1. How do I enable a waitlist in Dynamics 365 Customer Insights Journeys?

Open the event, go to the Capacity area, set the maximum event capacity, and enable the Waitlist option. You can then choose whether waitlisted contacts should be automatically registered when a seat becomes available.

2. What happens when a Dynamics 365 event reaches its maximum capacity?

New registrants are added to the waitlist instead of being registered directly. Their event registration record is created with the Waitlisted status reason.

3. Can Dynamics 365 automatically register contacts from an event waitlist?

Yes. Enable Auto-register waitlisted contacts on the event. When a registered attendee cancels and a seat becomes available, the longest-waiting contact can be automatically moved from Waitlisted to Registered.

4. What journey triggers are available for event waitlists?

Customer Insights Journeys provides two relevant triggers: Marketing event registration created, which can be used when a waitlist registration is created, and Marketing registration created from waitlist, which can be used when a waitlisted contact is moved to a confirmed registration.

5. Can I manually manage waitlisted registrations in Dynamics 365?

Yes. Waitlisted registrations can be reviewed and managed from the Event Registration records. You can also manually cancel registrations when required and use journeys or other automation to manage communication with waitlisted contacts.

The post Setting Up Event Waitlists in Dynamics 365 Customer Insights – Journeys first appeared on Microsoft Dynamics 365 CRM Tips and Tricks.

Modern Dynamics 365 applications often require intelligent automation to reduce manual effort and improve customer experience. Agent Nodes in Copilot Studio Agent Flows allow an existing AI agent to be invoked as part of a workflow. The flow can pass information to the agent, receive a structured response, and use that response in subsequent actions. In this example, a customer support email is analyzed by an agent, and the result is used to create a Dynamics 365 Case.

Key Takeaways

• Add an AI agent to Copilot Studio Agent Flows using the Run an agent
• Pass dynamic email subject and body to the agent at runtime.
• Use Text + JSON to return structured AI outputs.
• Automatically classify customer emails by category and priority.
• Use AI-generated results to create Dynamics 365 Cases.
• Replace manual triggers with automated email or business-event triggers in production.

Business Scenario

A customer support team receives requests that need to be classified before a Case is created. The requirement is to automatically analyze the incoming request and determine the appropriate routing information.

• Identify the case category, such as Billing, Technical, Sales, or General.
• Determine the priority: Low, Medium, High, or Critical.
• Generate a short summary of the customer’s issue.
• Use the AI-generated information while creating a Dynamics 365 Case.

Step 1: Create an Agent Flow

Navigate to: Copilot Studio → Flows → New Flow

Choose the Manually trigger a flow trigger.

Create the following trigger inputs:

Input Type (Text) – Email Subject (emailSubject), Email Body (emailBody)

This trigger is used only for demonstration purposes. In production, these values can come directly from Outlook, Dynamics 365, or another connector.

Step 2: Add the Agent Node

Click the + icon below the trigger and select: Run an agent

If prompted, sign in using your Microsoft account.

Select your published agent from the Agent dropdown.

Note: If the agent is not visible, verify that it has been published. Unpublished agents are not listed in the dropdown.

Step 3: Configure the Runtime Message

The Message field is the runtime input sent to the agent. Insert the trigger’s emailSubject and emailBody using dynamic content; do not hardcode the values in the flow.

Example message:
Analyze the following customer support email and identify the information required for case routing in Dynamics 365.

Email Subject:
[dynamic emailSubject]
Email Body:
[dynamic emailBody]
Based on the email, determine:
– Category (Billing, Technical, Sales, or General)
– Priority (Low, Medium, High, or Critical)
– A concise one-line summary of the issue.

Return the response using the JSON schema provided. Do not include any additional text, explanations, or markdown.

Step 4: Configure the Agent Response

Under Agent response as shown in the above screenshot, select Text + JSON. In the JSON section, define the expected structure so the flow can use each result as a separate output.

{
 “type”: “object”,
 “properties”: {
 “category”: { “type”: “string” },
 “priority”: { “type”: “string” },
 “summary”: { “type”: “string” }
 },
 “required”: [“category”, “priority”, “summary”],
 “additionalProperties”: false
}

This produces structured outputs such as category, priority, and summary that can be selected as dynamic content in later actions.

Step 5: Test the Agent

To test the Agent Flow, use a real customer email as the input for the manual trigger.

1. Run the flow using the Test
2. In the Email Subject field, enter the subject of a received customer email.
3. In the Email Body field, copy and paste the corresponding content of the email.
4. Execute the flow.

The email subject and body are passed dynamically to the Run an agent node. The agent analyzes the provided content according to its configured instructions and JSON schema.

After the flow completes, review the Run history to see the Agent Node’s response. The structured output will contain the properties configured in the response schema, such as:

{
  “category”: “Billing”,
  “priority”: “High”,
  “summary”: “Customer reports being charged twice for an invoice and requests investigation and refund.”
}

The actual values will vary depending on the email used for testing. These structured outputs can then be used by subsequent actions in the flow, such as creating or updating a Dynamics 365 Case.

Note: The manual trigger is used here only to simulate the receipt of a customer email. In a production implementation, the trigger can be replaced with an appropriate automated trigger so that the email content is passed to the Agent Node without requiring manual input.

Step 6: Use the Agent Output in Dynamics 365

The structured output from the Agent Node can now be used in a Dataverse action such as Add a new row to create a Case.

In this implementation:

• Title was mapped to the AI-generated Summary.
• Description was mapped to the Email Body.
• Customer was mapped by binding an existing Account through its OData ID.

Note: The Customer field on the Case table is a lookup field. It requires a valid Account or Contact reference (OData ID). Providing only the account name will result in an error.

Result

After running the flow successfully:

• The customer email was analyzed by the AI agent.
• The issue was classified automatically.
• Priority and summary were generated.
• A Dynamics 365 Case was created using the structured output returned by the agent.

This demonstrates how an Agent Node can intelligently process business data before it is consumed by Dynamics 365.

Conclusion

The Run an agent node makes it easy to integrate AI into Dynamics 365 workflows. By passing real-time data to an agent and using its structured output, tasks such as email analysis, case classification, and case creation can be automated efficiently.

FAQs

1. What is an Agent Node in Microsoft Copilot Studio?

An Agent Node, available through the Run an agent action in Copilot Studio Agent Flows, allows a workflow to invoke a published AI agent. The flow can pass dynamic information to the agent, receive a structured response, and use that output in subsequent actions such as creating a Dynamics 365 Case.

2. How do I add an Agent Node to an Agent Flow in Copilot Studio?

Create an Agent Flow in Copilot Studio, add a trigger, and select Run an agent from the available actions. Choose the required published agent, configure the runtime message, and define the expected response format. The agent can then process information passed from the flow.

The post How to Add an Agent Node to an Agent Flow in Microsoft Copilot Studio first appeared on Microsoft Dynamics 365 CRM Tips and Tricks.

Every sales pipeline eventually faces the challenge of managing increasing deal volume and complexity. As opportunities grow, sellers spend more time reviewing emails, updating notes, tracking interactions, and gathering information from different sources. Opportunities can also lose momentum when key contacts become unresponsive, decision-makers change, or competitors enter the discussion. Without a structured process for tracking these changes, such opportunities may not receive timely attention until a forecast or pipeline review.

The Sales Opportunity Agent in Dynamics 365 Sales helps streamline opportunity management by supporting sellers with opportunity research, prioritization, and risk identification. Instead of relying solely on manual reviews and dashboards, it can help surface relevant information and potential issues associated with open opportunities.

For CRM administrators and RevOps teams, implementing the agent requires appropriate configuration and preparation. This guide covers the key capabilities of the Sales Opportunity Agent, the benefits of configuring it, the prerequisites to consider, the main configuration steps, and how to validate the setup before making it available to sales users.

What is a Sales Opportunity Agent?

At a high level, the Sales Opportunity Agent in Dynamics 365 Sales helps sales teams monitor and manage open opportunities based on criteria defined by the administrator. It supports opportunity prioritization, risk identification, account research, and recommended actions, helping sellers focus on opportunities that may require attention.

The agent can be configured from the Dynamics 365 Sales AI Hub, with administrators defining which opportunities are included. Once configured, it can support the following activities:

1. Opportunity prioritization: Categorizes opportunities based on factors such as deal value, account information, and historical sales data.
2. Risk assessment: Reviews information available in CRM, including related activities and email interactions, to identify potential risks or areas requiring attention.
3. Opportunity research: Organizes relevant information about stakeholders, competitors, account details, business challenges, and other opportunity-related factors, with references to the available sources.
4. Recommended actions: Provides suggested next steps on the opportunity record based on the information and risks identified.
5. Scheduled updates: Runs according to the configured schedule, allowing opportunity information and related activities to be reviewed periodically.

This provides sellers with a more structured view of opportunity status, potential risks, and recommended follow-up actions without requiring them to manually review every source of information.

The agent can also use the predictive opportunity scoring model available in Dynamics 365 Sales as part of its risk assessment. If the required predictive scoring model is not already configured, the necessary setup may be initiated when the agent runs.

It is important to understand the scope of the Sales Opportunity Agent. Its primary purpose is to research, assess, and provide recommendations for opportunities. It does not independently contact customers or perform outbound sales activities. Customer outreach is handled through other Dynamics 365 Sales capabilities, such as the Sales Close Agent.

For administrators, clearly defining opportunity selection criteria and understanding how different sales capabilities interact is important when configuring the agent.

Why the Setup Effort Is Worth It?

For sales operations teams, configuring the Sales Opportunity Agent can provide several practical benefits across the sales process:

• Reduces manual research: Opportunity information, account details, stakeholder information, and competitive data can be organized within the opportunity, reducing the need for sellers to gather information manually from multiple sources.
• Identifies risks earlier: Changes in stakeholder engagement, missing key information, or other opportunity gaps can be highlighted earlier, allowing sellers and managers to address potential issues before they affect the deal.
• Creates consistent prioritization: Opportunities can be evaluated using consistent criteria, giving sales teams a more structured approach to determining which opportunities require attention.
• Improves pipeline visibility: Sales managers can review opportunities using consistent information and risk indicators, making pipeline reviews more structured and data-driven.
• Supports higher sales volumes: As the number of opportunities increases, standardized research and assessment processes can help reduce the additional administrative effort required from sellers.

Overall, the configuration helps establish a more consistent process for reviewing, prioritizing, and managing sales opportunities, while reducing the amount of manual effort required from sales teams.

Prerequisites

Before configuring the Sales Opportunity Agent, make sure your Dynamics 365 Sales environment, licenses, and user permissions meet the required prerequisites. These requirements can be grouped into general Sales agent requirements and prerequisites specific to the Sales Opportunity Agent.

General Requirements

• Administrator access: You should have the appropriate administrator permissions in the Dynamics 365 Sales environment to configure the agent.
• Copilot Studio license: A Copilot Studio license is required because the agent is configured and operates through Copilot Studio.
• Modern UI enabled: The modern user interface should be enabled for the Sales Hub app. Some agent configuration options and related views may not be available without it.
• Access to Dynamics 365 AI Hub: The administrator should be able to access General Settings > Dynamics 365 AI Hub. If this option is unavailable, review the user’s security roles and permissions.

Sales Opportunity Agent-Specific Requirements

• Required license or service access: At least one supported license or service should be available, such as a Microsoft 365/Office 365 license, Power Automate Premium, or Dynamics 365 Sales Enterprise/Premium Edition. This is required for accessing the opportunity owner’s email information and related insights.
• Email access configuration: Determine how email information will be accessed. The agent can use server-side synchronization to work with email data synchronized to Dynamics 365 Sales or direct Microsoft 365 Services access. Both options can also be enabled when required.
• Bing Search configuration: If the agent needs to use public information about accounts and competitors, ensure the required Bing Search terms are accepted and configured in the Power Platform admin center.
• Security roles: Confirm that sales users have the required permissions to view the agent’s information and recommendations. Standard Salesperson and Sales Manager roles provide the necessary access. If your organization uses custom security roles, verify that equivalent permissions have been assigned.

Completing these prerequisites before configuration helps avoid issues with agent visibility, email access, data availability, and user permissions during implementation.

Step-by-Step Configuration

Below is the click-by-click path to stand up a brand-new instance of the agent.

Step 1: Open the Sales Hub App

• Sign in to Dynamics 365 and launch Sales Hub from your app list.

Step 2: Get to the AI Hub

• In the bottom-left corner of the screen, open the Change area menu — by default it’ll say “Sales.”
• Choose App Settings from the menu that pops up.
• In the left navigation pane, scroll down until you see General Settings, then click Dynamics 365 AI Hub.

Step 3: Kick Off Agent Creation

• Under the Agent manager section, choose Create and manage agents.
  • First time here? You’ll hit a Prerequisites page — read through it and accept before moving on.
• Hit Create, then pick Sales Opportunity Agent from the list of agent types.

• Give it a name that actually means something later — “High-Value Enterprise Deals” will save you confusion down the road; “Test” will not.

Step 4: Fill in Profile and Company Details

• Click into the General tab.
• Fill out the Agent profile section — this is metadata the app uses internally.
• Complete the Company info section. This is what the agent references when it’s putting together competitor comparisons and account-level research, so it’s worth getting right.

Step 5: Set Your Selection Criteria

This is the step that decides which records actually get worked on. Spend real time here — sloppy criteria means the agent burns cycles researching deals that were never going anywhere.

• Head to the Selection criteria section.
• Build out conditions using AND logic. A reasonable starting baseline:
  • Field: Status | Operator: Equals | Value: Open
  • Field: Status Reason | Operator: Equals | Value: In Progress
  • Field: Estimated revenue | Operator: Is greater than | Value: [your target amount]
• Optional: turn on the “Consider opportunities created in the last [N] days” toggle if you’d rather scope the agent to a rolling window instead of pointing it at your entire historical pipeline.

Step 6: Configure Advanced Settings

• Open the Advanced section to fine-tune how the engine behaves.
  • Refresh frequency: how often the agent re-runs the full research pass — 3, 7, or 14 days are the typic
  • Opportunity assessment: the logic that decides how deal importance gets weighted.
  • Risk & Importance criteria: the specific thresholds that trigger each label.

Step 7: Save It and Turn It On

• Click Apply changes to save the configuration.
• Flip the agent’s toggle to On.
• Check the status indicator near the top of the page to confirm it’s actually running. You can come back to this same screen and click Stop agent any time you need to pause it.

Pro Tip: Running Multiple Agent Instances

Dynamics 365 Sales supports up to 10 active Sales Opportunity Agent instances per environment. Instead of using one instance with broad selection criteria, administrators can create separate instances based on business requirements, product lines, opportunity types, or deal segments.

For example, an organization could configure:

• One instance for large enterprise opportunities with a longer refresh interval.
• Another instance for smaller manually created opportunities that may not meet the primary instance’s selection criteria.

This approach allows each instance to have more focused selection criteria and refresh settings, making it easier to manage different types of opportunities.

Testing and Validation

Before enabling the agent across the entire sales pipeline, validate the configuration with a controlled set of opportunities. This helps identify selection, data, and permission issues before users start relying on the results.

1. Review the Preview

Use the Preview panel on the Selection criteria page to review a sample of opportunities that match the configured criteria.

The preview is intended as a representative sample and should not be treated as a guaranteed lookup for a specific opportunity. If you need to verify whether a particular opportunity meets the criteria, use an Opportunities view, Advanced Find, or a saved view with the same conditions.

2. Test with Known Opportunities

Start with a small number of opportunities that the sales team already understands well. Review whether the generated research, importance classification, and risk information are consistent with the information already available in Dynamics 365.

This provides a practical way to identify configuration or data issues before expanding the agent to the full pipeline.

3. Review the Generated Views

After the agent completes at least one processing cycle, review the associated views to confirm that opportunities are being categorized correctly:

• My top opportunities from AI agent – Review high- and medium-importance opportunities.
• Opportunities researched by AI agent – Review opportunities that have been researched.
• Deals at risk (AI agent) – Review opportunities where a risk has been identified.

If expected opportunities are missing, review the selection criteria and related configuration.

4. Apply Configuration Changes and Allow for Refresh

Changes to the selection criteria do not take effect until you select Apply changes. Also, the agent processes opportunities according to its configured refresh schedule rather than immediately after every record update.

After making changes, allow a complete processing cycle before concluding that an opportunity has not been picked up.

5. Review the Actual Research Results

Don’t limit validation to checking how many records were processed. Open several researched opportunities and review the information provided about:

• Stakeholders
• Competitors
• Account information
• Opportunity risks
• Recommended actions

Compare the results with information already known by the sales team. This can help identify issues with data availability, configuration, or external search results before the agent is made widely available.

A structured testing process ensures that the agent’s selection criteria, generated information, views, and refresh behavior are working as expected before it is introduced into the wider sales process.

Conclusion

The Sales Opportunity Agent helps teams research, assess, and prioritize opportunities in Dynamics 365 Sales while reducing manual effort.

A successful setup requires the right licensing, security roles, selection criteria, and data access. Start with a small set of opportunities, validate the results, and expand gradually.

With proper configuration, the agent can provide consistent opportunity insights, earlier risk identification, and better pipeline management.

FAQs

Q: Will the Sales Opportunity Agent contact my customers directly?

No. The Sales Opportunity Agent is designed for research and analysis and does not initiate outbound customer communication. Customer outreach is handled separately through the Sales Close Agent’s engage function, which can be configured and scoped independently. If both agents are running in the same environment, make sure their selection criteria do not overlap to avoid duplicate processing or, in some cases, conflicting risk labels on the same opportunity.

Q: Can I run more than one Sales Opportunity Agent instance at the same time?

Yes. You can have up to 10 active Sales Opportunity Agent instances per environment. This can be useful for organizations with different product lines or deal segments that require different thresholds, refresh frequencies, or knowledge sources. Instead of using one broad set of criteria, you can create separate instances to address specific business requirements.

Q: What happens to opportunities that fall below the revenue threshold?

A Sales Opportunity Agent instance only processes opportunities that meet its configured selection criteria. If an opportunity falls below the defined revenue threshold, that instance will not research it. If you need to cover lower-value opportunities as well, you can create a separate instance with criteria and a refresh cycle suited to that segment.

Q: Can I change the selection criteria after configuring the Sales Opportunity Agent?

Yes. You can update the selection criteria as your business requirements change. After making changes, select Apply changes for the updated criteria to take effect. The agent will then process opportunities according to its configured refresh schedule.

Q: How can I verify that the Sales Opportunity Agent is working correctly?

You can validate the configuration by reviewing the Preview panel, testing the agent with known opportunities, and checking the generated views after the agent completes a processing cycle. You can also review the generated research, risk information, and recommended actions to confirm that the results align with the information already available to your sales team.

The post Configuring the Sales Opportunity Agent in Dynamics 365 first appeared on Microsoft Dynamics 365 CRM Tips and Tricks.

Ever asked Copilot a perfectly reasonable business question and gotten back a shrug, even though the data was sitting right there in Dataverse? That’s usually not a Copilot problem. It’s a language problem. Your team doesn’t talk in table and column names; you talk in “client,” “deal,” “ARR,” and “in the oven.” The AI, left to its own devices, only knows what the schema tells it, and schemas are rarely written in plain English.

Microsoft’s answer to this is the Dataverse semantic model, a new piece of Dataverse Intelligence that’s now in public preview. I spent some time setting it up and testing it against my own environment, and this post walks through what it is, how to turn it on, and a real before-and-after example of it doing its job.

What the semantic model actually is

The simplest way to describe it: the semantic model is a layer that sits between your raw Dataverse schema and any Copilot or agent experience that reasons over your data. Instead of an AI agent guessing what a column named ikl_targetarr or a picklist value like 3 means, the semantic model gives it a business-aware understanding of your tables, built partly from what’s already in your environment and partly from vocabulary you define yourself.

Microsoft describes it as combining three building blocks, and once you see them laid out, it’s a lot easier to understand what you’re configuring and why:

• Data scope with semantic indexing: Which tables are actually included. Only tables in scope contribute to what an agent understands, so this is your first lever for both relevance and performance.
• System-inferred signals: Relationships, public views with join conditions, sub-grid views, form display names, and column/table descriptions that the model reads automatically from metadata you’ve already configured. Sample data rows can optionally feed in too, though that’s off by default.
• The glossary: The human-curated layer. This is where you tell the model the things it can’t infer on its own: acronyms, internal slang, and department-specific shorthand.

Worth calling out: system views such as Quick Find, Advanced Find, Associated, and Lookup views don’t feed the model, and neither do personal views. For forms, only the display name is picked up, not the layout. Polymorphic relationships aren’t supported yet. None of this is a dealbreaker, but it explains why a view you expect to contribute to the model sometimes just doesn’t.

Why this is worth your time?

Four things stood out to me as the practical payoff:

• Better accuracy: The agent is interpreting intent instead of pattern-matching against column names.
• Faster answers: A well-scoped model means less ambiguity for the agent to resolve at query time.
• Less setup work over time: The model pulls from metadata you already maintain and refreshes on its own as your schema evolves.
• Consistency across agents: Every agent pointing at the same semantic model shares the same understanding, so you don’t get three different answers to the same question from three different bots.

Setting it up

You’ll need System Administrator access for this. There are two admin surfaces involved before you ever touch the semantic model itself.

1. Microsoft 365 Admin Center

• Go to Copilot → Settings.
• Find “Dataverse data available in Microsoft 365 Copilot.”
• Choose the access level you want to allow for users querying Dataverse data through Microsoft 365 Copilot.

2. Power Platform Admin Center

• Open your target environment, then go to Settings → Product → Features, and turn on the following:
• Under Dataverse Search: “Turn on search indexing to support Dataverse intelligence (Work IQ) in AI and agent experiences” and “Show global search bar in all model-driven apps and turn on search indexing to support search-only experiences.”
• Under Dataverse Intelligence: “Allow data availability in Microsoft 365 Copilot” and “Turn on Dataverse intelligence for agents and AI experiences.”
• Turn on both toggles in both groupings. This is the step that actually provisions Dataverse Intelligence for the environment. The semantic model itself gets created automatically once this is enabled; you don’t provision it by hand.
• Note that your environment should be a managed environment to try this out.

3. Find the model in make.powerapps.com

• Head to make.powerapps.com and look for Semantic Models (preview) in the left navigation. Pin it; you’ll be back here often while you’re tuning glossary terms.
• A couple of things to expect the first time through:

• • Model creation kicks off automatically once Dataverse Intelligence is enabled, and initial generation can take up to two hours before anything shows up.

• This is a preview feature, so you can’t create a brand-new custom model yet. What you get out of the box is the SalesQnA model, pre-loaded with the standard sales entities, including Account, Opportunity, Lead, Product, and similar entities.

Configuring the model

Once the model exists, you get real control over it:

• Entity selection: Include or exclude tables to keep the model focused and fast.
• Relationships and views: For each table, choose which relationships and views actually feed the model. This helps it segregate data cleanly instead of drowning in noise.
• Glossary: Add or edit terms that map your organization’s day-to-day language onto specific tables, columns, and choice values.

The glossary is genuinely the interesting part, so let’s put it to a real test.

Before and after: putting the glossary to work

Here’s the scenario. My Opportunity table has a few customizations on top of the standard fields: an ARR-style revenue column, a deal category choice column with a “Hardware Refresh” option, and a deployment stage choice column with a “Scoping” option. Nothing exotic, just the kind of custom fields most CRM implementations end up with.

Before touching the glossary, I asked Copilot this, using the way my sales team actually talks:

“Calculate the total ARR for all refresh deals currently in the oven for the Contoso client.”

It failed. Not because the data wasn’t there; it clearly was. The problem was that the agent had no way to know that “ARR” meant a specific custom column, that “refresh” meant a specific choice value, that “in the oven” meant another choice value entirely, or that “client” meant Account. It tried, and it came back with something generic and wrong. That’s the exact gap the semantic model exists to close.

So I went into the SalesQnA model configuration, excluded everything except Account and Opportunity to keep regeneration quick, and added these glossary entries:

Glossary changes normally get picked up during the model’s regular 12-hour regeneration cycle, but you don’t have to wait. There’s a manual Regenerate button that syncs your changes on demand. I used it, waited for the status to flip from “Regenerating” back to a completed timestamp, cleared the chat, and asked the exact same question again.

This time, it worked. Correct records, correct math, and no follow-up clarification needed. Same question, same data; the only thing that changed was that the AI now had a translation layer between our internal shorthand and the actual schema.

Why centralize this instead of configuring it per agent?

If you’ve built agents in Copilot Studio before, this might feel familiar. You can already add synonyms and glossary terms when you add a Dataverse table as a knowledge source there. So what’s actually new?

The difference shows up the moment you need more than one agent. Say you’re building three or four agents for different teams, each grounded in the same Opportunity and Account data. Configuring glossary terms inside Copilot Studio means redoing that work agent by agent and keeping it in sync by hand as your terminology evolves. Define the same vocabulary once at the semantic model layer instead, and every consuming experience inherits it automatically. You maintain one glossary, not five.

It’s also just a cleaner architecture. You’re not duplicating grounding logic across bots; you’re centralizing it at the data layer and letting every agent on top of it stay consistent by default.

Where this shows up across the Microsoft AI stack

Once the semantic model is provisioned, Microsoft lists four experiences that consume it automatically. You don’t wire this up separately for each one:

• Copilot in Power Apps, inside model-driven apps.
• Microsoft 365 Copilot with Dataverse. This is also what powers the experience inside Teams, Outlook, and Word, since those all run on the same Microsoft 365 Copilot grounding rather than a separate configuration per app.
• Sales Agent in Microsoft 365.
• Copilot Studio agents that use Dataverse tables as a knowledge source.

A word of caution on scope: this list doesn’t currently include the Dataverse MCP Server. MCP is a separate, also-in-preview capability that exposes Dataverse tables and records as tools to MCP clients such as Copilot Studio, GitHub Copilot in VS Code, and Claude Desktop. Useful, but it’s a different integration path with its own governance and billing model, not a semantic-model consumer as of this writing.

If your goal is specifically to have Copilot Studio, Teams, or Microsoft 365 Copilot understand your business vocabulary, the semantic model and its glossary are the right layer. If your goal is to let a coding agent or an external LLM client query and manipulate Dataverse directly, that’s the MCP server, and it’s worth treating as a separate project with its own security review.

Current limitations to plan around

• No custom model creation yet: You’re working with the out-of-the-box SalesQnA model during preview.
• No ALM support: Environment copy or move operations aren’t carried over cleanly. After any copy or move, turn Dataverse Intelligence off and back on in the Power Platform Admin Center to force the model to reprovision.
• It’s preview, full stop: Don’t treat this as production-hardened yet, and keep an eye on the release notes as it matures toward general availability.

Conclusion

The real value here isn’t the demo-friendly “boom, it worked” moment; it’s what it replaces. Without this, closing the gap between how your business talks and how your schema is named means teaching every single agent your vocabulary by hand and hoping you remember to keep them all in sync. The semantic model turns that into a one-time investment: define your glossary once, scope your entities sensibly, and every Copilot experience sitting on top of Dataverse inherits that understanding automatically.

It’s still in preview, and there are real gaps. No custom models, no ALM story yet, but the direction is right. For anyone building or maintaining Copilot-grounded experiences on Dataverse, this is worth setting up in a sandbox environment now, so you’re not starting from zero when it reaches general availability.

Frequently Asked Questions

Does Copilot respect Dataverse security roles?

Yes. The semantic model doesn’t bypass Dataverse security. Copilot still operates within the permissions of the user making the request, so users can only access data they are authorized to see through their Dataverse security roles. The semantic model improves how Copilot understands the data; it does not change the underlying access controls.

What happens when security permissions change?

Changes to Dataverse security roles and permissions continue to apply to Copilot experiences. If a user loses access to a table or record, the semantic model doesn’t grant that access back. This distinction is important when implementing Dynamics 365 professional services, because semantic understanding and data security should be managed as separate layers.

Can it understand N relationships?

The semantic model can use supported relationships and relationship metadata to understand connections between tables, but polymorphic relationships are currently not supported. For more complex relationship structures, test the queries you expect users to ask rather than assuming every relationship will be interpreted automatically.

Can I include custom tables?

Custom tables can be included where they are supported by the semantic model configuration. This is particularly useful for organizations that have extended their CRM beyond the standard Account, Opportunity, Lead, and Product tables. If those custom tables are part of a larger Dynamics CRM development project, keeping their names, descriptions, relationships, and views well defined can also improve how the semantic model interprets them.

Can I include custom columns?

Yes. Custom columns can contribute to the semantic model, which is especially useful when your business uses internal terminology that doesn’t match the column’s technical name. The glossary can then connect terms such as “ARR” or “renewal value” to the appropriate custom column. This can be valuable in environments built through Dynamics CRM development services, where custom fields often reflect organization-specific processes.

Can I use custom entities with SalesQnA?

The current preview experience is centered around the out-of-the-box SalesQnA model and its supported tables. While you can configure the tables and data that contribute to the model, custom model creation is not currently available. If your SalesQnA scenario depends heavily on custom entities, validate the supported configuration in your environment before designing the full solution around it.

How do I connect a Copilot Studio agent to the semantic model?

You don’t typically connect the semantic model to each agent as a separate integration. Once the semantic model is provisioned and configured, supported Copilot experiences, including Copilot Studio agents using Dataverse tables as a knowledge source, can consume the semantic understanding. This is one reason Dynamics 365 Copilot services can benefit from a centralized semantic layer when multiple agents work with the same business data.

How do I maintain Dev → Test → Production?

This is one of the current limitations to plan for. The semantic model does not yet provide a mature ALM experience, so you shouldn’t assume that environment copy or move operations will carry everything over cleanly. During the preview, Microsoft recommends reprovisioning Dataverse Intelligence after certain environment operations. Teams using Dynamics 365 professional services should therefore include semantic model configuration and validation in their environment management process.

Can it be deployed through Azure DevOps?

The semantic model currently doesn’t have the kind of mature ALM support you’d normally expect for a solution that is fully managed through Azure DevOps pipelines. Treat the semantic model configuration separately from your standard solution deployment process until Microsoft provides broader ALM support. For organizations managing Dynamics 365 development services through structured DevOps practices, this means including a manual validation or reprovisioning step where required.

What licenses are required for the Dataverse semantic model?

The Dataverse semantic model is currently a preview capability, so licensing can depend on the Microsoft 365 Copilot, Dynamics 365, and Power Platform capabilities you’re using alongside it. You should verify the current Microsoft licensing requirements for your specific environment before enabling it. If your implementation involves broader Dynamics 365 development services, licensing and environment architecture should be reviewed together rather than in isolation.

The post Teaching Copilot Your Business Language: A Hands-On Look at the Dataverse Semantic Model first appeared on Microsoft Dynamics 365 CRM Tips and Tricks.

Organizations are increasingly using Microsoft 365 Copilot agents to simplify everyday tasks and support business processes across industries such as healthcare, finance, HR, and customer service. But deploying an agent is only the first step. To get the most value from it, you also need to understand how people are actually using it.

Which agent is getting the most attention? Are users coming back regularly? Is adoption growing over time? These insights can help you understand whether your Copilot agents are making an impact and where there may be opportunities to improve adoption.

This is where the Microsoft 365 Insights Agent can help. Instead of spending time going through usage reports, administrators can simply ask questions in natural language and get insights into agent adoption, active users, usage trends, and more. This makes it easier to see how your Copilot agents are performing and understand how users are engaging with them.

Real Business Use Case: Healthcare Copilot Agents

Consider a healthcare organization that has deployed two Microsoft 365 Copilot agents to improve clinical efficiency.

The Patient Care Assistant helps doctors and nurses quickly retrieve patient information, medication history, appointment details, and treatment guidelines during consultations. The Medical Documentation Assistant supports clinicians by generating patient summaries, discharge notes, and other medical documentation, reducing the time spent on administrative tasks.

After deploying both agents, the IT and healthcare teams want to understand how effectively these solutions are being adopted. They need answers to questions such as:

• Which agent has higher user adoption?
• How many users interact with each agent daily or weekly?
• Are users returning consistently over time?
• Which agent requires additional improvements or user training?

Rather than manually analyzing reports, the Microsoft 365 Insights Agent enables administrators to retrieve these insights simply by asking questions in natural language.

Before getting started, make sure you have:

• A Microsoft 365 Copilot license assigned to your account.
• Access to at least one deployed Copilot agent in your tenant.
• A few days of agent usage data to generate meaningful adoption and usage insights.

Step 1 – Open Microsoft 365 Copilot

Open  Microsoft 365 Copilot Chat and navigate to the Insights Agent.

Step 2 – Select an agent

Select the deployed Copilot agent you want to analyze. The Insights Agent can retrieve usage information for any agent that you have access to within your tenant, regardless of ownership. For this example, we’ll analyze:

• Patient Care Assistant
• Medical Documentation Assistant

Step 3 – Retrieve Usage Insights

Ask the Insights Agent a natural language question.

Example: Provide all usage insights for Patient Care Assistant

The Insights Agent returns adoption metrics such as:

• Daily Active Users (DAU)
• Weekly Active Users (WAU)
• Monthly Active Users (MAU)
• User adoption trends
• Overall usage summary

These metrics help determine how frequently healthcare professionals rely on the Patient Care Assistant during their daily workflow.

Step 4 – Try a comparison

1. Compare DAU and WAU for Patient Care Assistant

This prompt compares the Daily Active Users (DAU) and Weekly Active Users (WAU) for the Patient Care Assistant, helping you evaluate user engagement and adoption over different time periods.

2. Compare Patient Care Assistant with Medical Documentation Assistant

One of the most useful capabilities of the Insights Agent is comparing multiple Copilot agents.

This comparison helps you analyze the adoption and usage of both healthcare agents, making it easier to understand user engagement and identify areas for improvement.

Step 5 – Explore Additional Insights

Beyond comparing agents, the Insights Agent can answer a variety of usage-related questions.

Some useful prompts include:

• Show Daily Active Users for Patient Care Assistant.
• Show Weekly Active Users for Medical Documentation Assistant.
• Compare monthly adoption between both agents.
• Summarize usage trends for my Copilot agents.
• Which agent has the highest adoption?

Conclusion

Building a Microsoft 365 Copilot agent is just the beginning. To get lasting value from your AI investments, it’s equally important to understand how users interact with these agents and whether adoption is growing over time.

The Microsoft 365 Insights Agent makes this easier by giving administrators access to usage analytics through natural language conversations. Whether you’re tracking a single agent or comparing multiple solutions, you can quickly understand adoption trends, user engagement, and areas that may need attention.

As we saw with the Patient Care Assistant and Medical Documentation Assistant, these insights can help healthcare organizations make better-informed decisions about their Copilot agents. By understanding what’s working and where adoption can improve, organizations can support users more effectively and get greater value from their AI investments.

Frequently Asked Questions (FAQs)

1. What is the Microsoft 365 Insights Agent?

The Microsoft 365 Insights Agent helps administrators analyze usage and adoption of Microsoft 365 Copilot agents. You can ask questions in natural language to get insights into active users, usage trends, and agent adoption.

2. How can I measure Microsoft 365 Copilot agent adoption?

You can measure Copilot agent adoption by reviewing usage metrics such as Daily Active Users (DAU), Weekly Active Users (WAU), and Monthly Active Users (MAU). Comparing these metrics over time can help you understand how consistently users are engaging with your agents.

3. What usage metrics can the Microsoft 365 Insights Agent provide?

The Insights Agent can provide metrics such as Daily Active Users (DAU), Weekly Active Users (WAU), Monthly Active Users (MAU), user adoption trends, and overall usage summaries.

4. Can I compare the usage of multiple Copilot agents?

Yes. The Microsoft 365 Insights Agent can help you compare the usage and adoption of multiple Copilot agents. This can help you identify which agents have higher engagement and which may need additional improvements or user training.

5. What questions can I ask the Microsoft 365 Insights Agent?

You can ask the Insights Agent natural language questions about your Copilot agents. For example, you can ask it to show Daily Active Users, compare monthly adoption between agents, summarize usage trends, or identify which agent has the highest adoption.

The post How to Analyze Copilot Agent Adoption Using Microsoft 365 Insights Agent first appeared on Microsoft Dynamics 365 CRM Tips and Tricks.

Business documents such as purchase orders, invoices, reports, and shipping documents often contain valuable information in tabular format. In many organizations, this information is still copied manually into spreadsheets or business applications, which takes time and increases the possibility of errors.

Microsoft Copilot Studio includes Computer Use, a capability that enables an agent to interact with applications through their user interface. Instead of depending on APIs or custom integrations, the agent can automatically open applications, navigate through screens, identify information, and complete tasks based on what it sees on the screen.

In this blog, we’ll build a practical solution that uses Computer Use to open a PDF document, identify the primary table, and extract its contents into a structured JSON format. The extracted data is then passed to a Power Automate flow, which converts it into a CSV file and sends it as an email attachment. This demonstrates how AI-driven UI automation can simplify document processing while reducing manual effort.

Let’s consider a potential use case:

Many organizations store business documents such as purchase orders, invoices, and reports in SharePoint document libraries for centralized access and collaboration. These documents often contain important tabular information that needs to be extracted and shared with other teams or business applications. Performing this task manually requires users to open each PDF, identify the required table, and copy the data into a structured format, making the process repetitive and prone to errors.

In this scenario, a purchase order PDF is stored in a SharePoint document library. A Copilot Studio agent uses Computer Use to open the PDF directly from SharePoint, identify the primary table containing the line-item details, and extract the data into a structured JSON format. The extracted data is then passed to a Power Automate flow, which converts it into a CSV file and sends it as an email attachment. This approach reduces manual effort and provides a simple way to automate document processing using AI-driven UI automation.

What You’ll Learn

By the end of this article, you’ll know how to:

• Configure a Computer Use tool in Microsoft Copilot Studio.
• Extract tabular data from a PDF stored in SharePoint.
• Pass the extracted JSON to Power Automate.
• Generate a CSV file from the extracted data.
• Email the CSV file automatically using Outlook.

Let’s go through the end-to-end implementation of this solution.

Prerequisites:

Before we get started, ensure you have the following:

• A Microsoft Copilot Studio environment with Computer Use enabled.
• A Microsoft 365 tenant with SharePoint Online available.
• A SharePoint document library containing the PDF document to be processed.
• A Power Automate environment to create the flow that converts the extracted JSON into a CSV file and sends it via email.
• An Outlook connection configured in Power Automate to send emails.
• A sample PDF containing tabular data (for this blog, a Purchase Order PDF is used).

Step 1:

Sign in to Microsoft Copilot Studio by navigating to https://copilotstudio.microsoft.com/. Once you’re signed in, open your agent and select Tools from the left navigation menu. Click Add tool, select New tool, and then choose Computer use to create a new Computer Use tool.

Step 2:

Click Add and configure to create the Computer Use tool. This opens the configuration page where you can define the execution environment, authentication settings, and instructions for the agent. For now, keep the default configuration, as we will add the instructions for the Computer Use agent in a later step.

Step 3:

The Computer Use tool configuration page will open. Enter an appropriate Name and Description for the tool. Under the Model section, select Claude Sonnet 4.5, as it provides the capabilities required for performing Computer Use tasks. Once the basic configuration is complete, click Save to proceed.

Step 4: Add the Computer Use Instructions
The next step is to provide instructions that guide the Computer Use tool on how to interact with the PDF. These instructions tell the agent where the PDF is located, how to handle authentication, identify the required table, and return the extracted data in a structured JSON format.

Copy and paste the following instructions into the Instructions section of the Computer Use tool.

You are an intelligent document extraction assistant.
Your task is to extract the primary tabular data from a PDF document.
Open Microsoft Edge.
Navigate to: Please paste the sharepoint document folder link
If authentication is required:
– Use the stored username.
– Use the stored password.
– If Multi-Factor Authentication (MFA) is requested, pause and wait for the user to approve it.
– Continue automatically after authentication succeeds.

Wait until the PDF is fully loaded.
Examine the document to identify the main table containing business data.
Ignore logos, headers, addresses, titles, summaries, footers, and terms & conditions.
Focus on the largest table containing rows of business records or line items.
If the table spans multiple pages:
– Scroll through the document.
– Continue extracting rows until the complete table has been captured.
– Do not stop after the first page.

Preserve the original column names from the table header.
Extract every row exactly as displayed.
Use the following data types consistently:
– Line: String
– Qty: String
– Item Code: String
– Description: String
– UOM: String
– Unit Price: String
– Amount: String

Return ONLY a valid JSON array.
Each JSON object should represent one row.
Use the actual column names from the PDF as the JSON property names.
Do not include explanations, markdown, summaries, or additional text.
Return only valid JSON.

Step 5: Configure the Execution Settings
Next, configure the execution settings for the Computer Use tool. Set the Outputs type to Text, as the agent will return the extracted table data in JSON format. Under Machine, select Hosted Browser to execute the automation in a Microsoft-hosted browser session. Finally, set Credentials to use to End user credentials so the agent can authenticate using the credentials configured for the end user.

Step 6:
Under Human supervision, assign a reviewer who can receive and respond to requests from the Computer Use agent. Human supervision allows the agent to contact a designated reviewer for confirmation or to request additional information whenever manual intervention is required during execution. These notifications are sent through Outlook. Set the Response time limit to 1 Hour.

Next, under Stored credentials, click Add and configure the credentials that the agent will use to sign in to the SharePoint site. Store the username and password for the Microsoft sign-in page (for example, login.microsoftonline.com). During execution, the Computer Use agent automatically uses these stored credentials to authenticate. If additional verification, such as Multi-Factor Authentication (MFA), is required, the assigned reviewer can respond to the agent’s request and allow the execution to continue.

Step 7:
Sign in to Power Automate by navigating to https://powerautomate.microsoft.com/. From the left navigation pane, select Create, choose Instant cloud flow, and then select the When an agent calls the flow trigger. This trigger enables the flow to be invoked directly from a Copilot Studio agent, allowing it to process the data extracted by the Computer Use tool.

Provide an appropriate name for the flow and click Create to continue.

Step 8:
In the When an agent calls the flow trigger, add a Text input named ExtractedJson. This input will receive the JSON data returned by the Computer Use tool.

Next, add a Parse JSON action and set the Content field to the ExtractedJson input. Generate the schema using a sample of the JSON returned by the Computer Use agent. This enables Power Automate to interpret the extracted data and make each property available for subsequent actions.

After parsing the JSON, add the Create CSV table action. Set the From field to the Body output of the Parse JSON action. This converts the extracted table data into a CSV format that can be used in downstream actions, such as sending it as an email attachment.

This step prepares the extracted PDF data for further processing within the flow.

Step 9:
After generating the CSV data, add a Create file action (OneDrive for Business) to save the CSV file temporarily. Specify the destination folder, provide a meaningful file name (for example, PurchaseOrder_<timestamp>.csv), and set the File Content to the Output from the Create CSV table action.

Next, add a Get file content action and set the File field to the Id returned by the Create file action. This retrieves the contents of the generated CSV file, allowing it to be used in subsequent actions, such as sending it as an email attachment.

Step 10:
Add a Send an email (V2) action to the flow. Configure the recipient’s email address, provide an appropriate subject, and compose the email body. Under Attachments, use the file content obtained from the Get file content action and specify the CSV file name. This sends the generated CSV file as an email attachment to the intended recipient.

Finally, add the Respond to Copilot action. Return a success response indicating that the flow completed successfully. For example, you can return the following JSON:

{

“Status”: “Success”,

“Message”: “CSV generated and emailed successfully.”

}

Step 11:
Save and enable the Power Automate flow. Return to your Copilot Studio agent and edit the agent instructions to orchestrate the complete process. The instructions should direct the agent to invoke the Computer Use tool to extract the table data from the PDF and then pass the extracted JSON to the Power Automate flow for further processing.

For example, you can use instructions similar to the following:
Whenever a PDF is added or updated in the specified SharePoint document library, invoke the Computer Use tool to extract the primary table from the PDF. Once the extraction is complete, pass the returned JSON to the Power Automate flow to generate a CSV file and email it to the configured recipient.

After saving the instructions, publish the agent. The agent is now configured to use the Computer Use tool for PDF table extraction and the Power Automate flow for generating and emailing the CSV output.

Test Results:
After publishing the Copilot Studio agent, invoke it by providing a prompt to extract the table from the Purchase Order PDF stored in the SharePoint document library.

During execution, the agent performs the following actions:

• Opens the PDF directly from SharePoint using the Computer Use tool.
• Authenticates using the configured stored credentials.
• Identifies the primary table containing the purchase order line items.
• Extracts the complete table into a structured JSON format.
• Invokes the Power Automate flow.
• Converts the JSON data into a CSV file.
• Sends the generated CSV file as an email attachment to the configured recipient.

Conclusion: In this blog, we built an end-to-end solution using Microsoft Copilot Studio Computer Use and Power Automate to automate the extraction of tabular data from a PDF stored in SharePoint. The Computer Use tool interacted with the PDF through its user interface, extracted the required table into a structured JSON format, and passed the data to a Power Automate flow. The flow then converted the extracted data into a CSV file and emailed it to the intended recipient.

Frequently Asked Questions (FAQs)

1. What is Computer Use in Microsoft Copilot Studio?

Computer Use is a capability in Microsoft Copilot Studio that enables agents to interact with applications through their graphical user interface (GUI). Instead of relying on APIs, the agent can open applications, navigate screens, extract information, and perform tasks based on what it sees.

2. Can Copilot Studio extract data from PDF files?

Yes. By using the Computer Use capability, a Copilot Studio agent can open PDF documents, identify tables or other relevant information, and extract the data into a structured format such as JSON for further processing.

The post Automating PDF Data Extraction Using Computer Use within Copilot Studio first appeared on Microsoft Dynamics 365 CRM Tips and Tricks.