Copilot and agents in Dynamics 365 Customer Engagement

Copilot in Customer Engagement: Beyond the feature toggle

Almost every Dynamics 365 Customer Engagement project I start today includes the same question from the business: "What can Copilot do for us?" The honest answer is that it depends on which Copilot you mean. Some capabilities are switched on in an admin center in an afternoon; others are agents you design, test and maintain like any other part of your solution.

In this article I walk through how I approach Copilot and agents on CE projects: what the built-in experiences in Sales and Customer Service give you, how to build Copilot Studio agents grounded in your own Dataverse data, how to govern all of it, and where to draw the line between configuring and building.

Three layers you need to tell apart

Before any workshop, I make sure everyone in the room uses the same vocabulary. In practice there are three layers:

• Built-in Copilot in the apps: record summaries, email drafting and meeting preparation in Sales; answers, response drafting and summaries in Customer Service. These are first-party features you enable and tune, not build.
• Microsoft-provided agents: prebuilt agents that Microsoft ships for sales and service scenarios, increasingly surfaced in Microsoft 365 Copilot as well as inside the Dynamics 365 apps. You configure their data sources and permissions, but you do not own their logic.
• Custom agents in Copilot Studio: agents you design yourself, with your own instructions, knowledge sources, tools and topics. These are solution components that belong in your ALM process.

Most disappointment with Copilot comes from mixing these layers up: expecting a feature toggle to understand a custom data model, or building a custom agent for something the product already does well.

Copilot in Dynamics 365 Sales

Copilot in Sales is a chat and summarization assistant embedded in the Sales app. It summarizes leads, opportunities and accounts, highlights recent changes to records, helps sellers prepare for meetings, drafts emails and can answer questions from SharePoint documents. Microsoft describes the full feature set in the Copilot in Dynamics 365 Sales overview.

What makes it work well

• Clean, complete data: a summary of an opportunity with an empty description, no activities and no stakeholders is just an empty summary with better grammar.
• Custom columns in summaries: review which fields are used for lead and opportunity summaries (4 to 15 fields, and at most 10 for recent changes) and add the custom columns your sellers actually rely on. Repeat this in the Sales agent configuration.
• Activity discipline: meeting preparation and recent-change summaries only reflect what is in Dataverse. If emails and appointments are not tracked, Copilot cannot see them.
• Security model: Copilot only reads records and files the signed-in user has access to, so a well-designed business unit and team structure carries over automatically.

Microsoft also positions the Sales agent in Microsoft 365 Copilot as the evolution of this experience, so sellers who live in Outlook and Teams get the same CRM context there. Check the current documentation for your tenant before you design training material around one specific entry point.

Copilot in Customer Service and Contact Center

For service teams, the most valuable features are usually the Copilot help pane (ask a question, draft a response, compose an email) and conversation and case summaries. Configuration happens in the Copilot Service admin center, including preset, representative and automated filters (up to five of each) that restrict which knowledge articles Copilot uses. See Configure Copilot features in the help pane.

Your knowledge base is the real project

The quality of answers in the help pane is largely determined by the knowledge sources behind it. On service projects I plan time for:

• Knowledge article clean-up: archive outdated articles, remove duplicates and make sure each article answers one question clearly.
• Metadata for filters: tag articles with product, language or region so preset, representative and automated filters can narrow answers to the right context.
• Language coverage: for Belgian service desks working in Dutch, French and English, decide which languages you maintain articles in, and test Copilot in each of them.
• Feedback loop: use the thumbs up and thumbs down feedback from representatives to find articles that need rework.

Building Copilot Studio agents on Dataverse

When the built-in experiences are not enough, for example an internal agent that answers questions about contracts, installed base or service level agreements stored in custom tables, Copilot Studio is the tool. Dataverse tables can be added directly as a knowledge source; Microsoft documents the steps in Add Dataverse tables as a knowledge source.

Prerequisites that are easy to miss

1. Dataverse search must be turned on in the environment, and the tables and columns you want to use must be included in the search index.
2. The agent must use the "Authenticate with Microsoft" option. Agents without authentication or with manual authentication cannot use Dataverse knowledge, which also means data is retrieved in the context of the signed-in user.
3. A single Dataverse knowledge source can contain up to 15 tables, so group tables by business domain rather than adding everything at once.
4. The maker needs access to the underlying data: tables a maker cannot read will not show up during setup.

Teach the agent your data model

Custom tables come with publisher prefixes, technical column names and choice values that mean nothing to a language model. Copilot Studio lets you add synonyms for columns and glossary terms for business vocabulary. Together with clear agent instructions, this is where most of the answer quality comes from. A simplified example of what I write for a service contract agent:

# Agent instructions (excerpt)
You help account managers answer questions about service contracts.
Only use the Dataverse knowledge source "Service contracts".
If a question is about pricing or legal terms, say you cannot answer
and suggest contacting the contract manager.
Always mention the contract number when you refer to a contract.
Answer in the language the user writes in (Dutch, French or English).

# Column synonyms
crx_contractnumber   -> contract number, contract reference, contract id
crx_enddate          -> end date, expiry date, renewal date
crx_slalevel         -> SLA, service level, support level

# Glossary terms
active contract      -> a crx_servicecontract row where statecode is Active
                        and crx_enddate is today or later
expiring contract    -> an active contract with crx_enddate within 90 days
key account          -> an account where crx_accounttier is "Key"

Actions, not just answers

An agent that answers questions is useful; an agent that can also act is where the value grows. Tools let the agent call connector actions or agent flows, for example to create a case or update a record. My rules of thumb:

• Reuse server-side logic: if a business rule already lives in a plugin or a Dataverse custom API, call it through the Dataverse connector instead of re-implementing it in a flow.
• Keep write actions narrow: expose "create a follow-up task for this account" rather than a generic "update any record" tool.
• Confirm before writing: let the agent summarize what it is about to change and ask the user to confirm.
• Make agent activity traceable: make sure records created by agents are identifiable, for example through an origin column, so you can audit and report on them.

Configure or build?

This is the table I use with customers to decide where the effort should go:

Governance: Decide before you build

Data policies

Copilot Studio agents are governed by Power Platform data policies (formerly DLP policies), and enforcement applies to all tenants. You classify Copilot Studio connectors as business, non-business or blocked. See Configure data policies for agents.

• Require user authentication for agents unless you deliberately publish a public website agent.
• Block HTTP requests and unapproved connectors as tools in general-purpose environments.
• Restrict the channels agents can be published to, per environment.
• Use a separate, tightly governed environment for customer-facing agents.

Managed environments

I recommend running production CE environments that host agents as managed environments. They add governance controls such as sharing limits, solution checker enforcement and usage insights, and they make it easier to apply consistent rules through environment groups instead of configuring environment by environment.

Data residency for European customers

For environments hosted in Europe, Microsoft documents that generative AI features use an Azure OpenAI endpoint within the EU Data Boundary. Some features, such as web search powered by Bing, process data outside the region and require an administrator to allow data movement across regions in the Power Platform admin center. Since March 2026, EU environments also show a separate "Allow flex routing during periods of peak load" setting (on by default for new tenants), Bing search and Microsoft 365 services have their own consents, and environment groups can enforce these choices through the Generative AI settings rule. Read Move data across regions for copilots and generative AI features.

Security roles still apply

Both Copilot in the apps and Dataverse knowledge in authenticated agents work in the context of the signed-in user. That is good news, but it also means Copilot will surface every record a user can technically read. If your security model is too permissive today, an agent will make that visible very quickly. Review broad organization-level read privileges before rollout, not after.

Agents belong in solutions

Create agents inside a custom solution from day one, with connection references and environment variables for anything environment-specific. You can then move them with the same pipeline as the rest of your CE customizations. After import, reconfigure user authentication and republish the agent; icon and channel settings do not travel with the solution. See Export and import agents using solutions.

With the Power Platform CLI, deploying an agent looks exactly like deploying any other solution:

# Export the solution that contains the agent from Dev (as managed)
pac auth create --name CRX-Dev --environment https://yourorg-dev.crm4.dynamics.com
pac solution export --name ServiceContractAgent --path ./out/ServiceContractAgent_managed.zip --managed

# Generate a settings file for connection references and environment variables
pac solution create-settings --solution-zip ./out/ServiceContractAgent_managed.zip --settings-file ./deploy/test.settings.json

# Import into Test with environment-specific values
pac auth create --name CRX-Test --environment https://yourorg-test.crm4.dynamics.com
pac solution import --path ./out/ServiceContractAgent_managed.zip --settings-file ./deploy/test.settings.json

Lessons learned

• Starting with the technology: begin with two or three concrete use cases and success criteria, not with "let's turn on Copilot".
• Underestimating content work: knowledge articles, descriptions and glossary terms take more time than configuring the agent itself.
• Testing in one language only: an agent that answers well in English may behave differently in Dutch or French. Test with real questions from real users in each language.
• Building agents in the default environment: agents created there are hard to govern and to move. Use dedicated development environments and solutions.
• Ignoring capacity: Dataverse search indexes and agent usage consume capacity. Agree on monitoring and ownership before go-live.
• No owner after go-live: agents need someone who reviews analytics, unanswered questions and feedback every month.

Conclusion

Copilot in Dynamics 365 Customer Engagement is not a single feature but a stack: built-in assistance you configure, Microsoft-provided agents you connect, and custom Copilot Studio agents you build and own. Start with the built-in features, invest in data and knowledge quality, build custom agents only where your own data model or processes require it, and put governance, data residency and ALM in place before the first agent reaches production. Treated that way, agents become a reliable part of your CE solution instead of an experiment.