How to enable and configure Service Agent in D365

Posted by: Dian Taylor | on August 11, 2026

In my last post I wrote about the Service Agent in Dynamics 365 Customer Service and its capabilities. I discussed what it is, what it is capable of and how it can help customer service teams work more efficiently. If you haven’t read the article I would recommend doing that first, you can find it here. Now that you know what the Service Agent can do, it’s time to get it up and running. In this article, I’ll walk you through all the steps to enable and configure the Service Agent, explain the key settings you’ll need to review, and share a few tips to help ensure a smooth setup. I ran into a few issues myself while trying to get the agent set up, which is the main reason I am writing the article. Let’s get started!

Prerequisites

It’s important to understand that you need to have the correct roles in the environment, otherwise you won’t be able to finish some of the required steps. The first thing we’ll do is install the Service app in Teams, after that we’ll need to add M365 Copilot to the Customer Service Workspace model driven app in your D365 Customer Service environment. Yes you read that right, you need to have M365 Copilot in order to access the Service Agent. According to the Learn docs, there are two admin roles that need to be assigned to the user that will enable the Service Agent. They’ll need to have the Microsoft 365 Admin role to install the Service app and you’ll need a Dynamics 365 Admin role to add M365 Copilot to the Customer Service Workspace App.

Install Service App

Let’s start with installing the Service app. By doing this we connect the Service Agent to your customer service environment. Go to marketplace to install the Service App, here is the link to the Service app. If you’re not signed in yet, you will be asked to log in. Click on ‘Get it now’ to start the installation process. (image below) NOTE: If you are seeing an error message, you might not have the correct roles (mentioned above) associated to your user record. If you don’t see an error after clicking the ‘Get it now’ button, you’ll be taken to Microsoft Teams. Another window opens up from where you can add the Service app to the environment. Shortly after you click ‘Add’, you should see the ‘Added Successfully’ screen from where you can open the Service Agent.

Add M365 Copilot to Model Driven App

The next step in the process is to add M365 Copilot to the Customer Service Workspace app. There are a few prerequisites that you need to configure before adding it to the CSW app. Most of these are quick configuration changes, but they’re important because the Service Agent relies on both Microsoft 365 Copilot and Dataverse to work! You have to make sure your Microsoft 365 tenant is configured to allow Dataverse data to be used by Microsoft 365 Copilot. You can do this by navigating to the M365 Admin center, expanding Copilot on the left sidebar, accessing ‘Settings’ and clicking ‘View All’ on the top of the screen.
From here you’ll need to find the setting ‘Dataverse data available in Microsoft 365 Copilot’. In the window that opens you’ll need to choose ‘All users’ or ‘Specific Groups’ under the ‘Allow users to access ‎Dataverse‎ data in ‎Microsoft 365 Copilot‎’ header. Save the changes to complete the setup.
You’ll also need to make sure Dataverse Search is enabled (set to Default or On) for the environment where you’re deploying the Service Agent. This can be done by navigating to https://aka.ms/ppac (this is the power platform admin center). Click on ‘Manage’ on the left side of the screen and select the correct environment. Click on ‘Settings’ and expand ‘Products’ and access ‘Features’. You’ll see the Dataverse search settings on the top right of the screen. Make sure the ‘Turn on search indexing to support Dataverse intelligence (Work IQ) in AI and agent experiences’ checkbox is enabled. You also have to make sure M365 Copilot has been enabled for your environment. Here are the steps to do this.

Now that the prerequisites are done, we can add M365 Copilot to the Customer Service Workspace App. (This will add the Copilot switcher on the top of the app, allowing users to use M365 Copilot in the app.) We can do this by navigating to make.powerapps.com and selecting the correct environment. (Please note you can follow these steps to add M365 Copilot to other model driven apps if needed.) Navigate to ‘App’ on the left sidebar. Change ‘My Apps’ to ‘All’ if you don’t see the Customer Service Workspace app. Hover your mouse over the app name and select the pencil icon. This will open the app in edit mode. Once the app loads, we’ll need to access the apps settings by clicking the ‘settings’ button on the command bar on the top of the screen. In the ‘Feature’ section of the app you will need to enable the ‘Enable M365 Copilot in model-driven apps’ setting. Once that is done, don’t forget to save the app and publish.

Configure Service Agent

The configuration of the Service Agent is not what we’re used to. There is no admin page where we can log into and configure the agent, all of the configurations are done by simply chatting with the agent! To do this we need to access the Service Agent, which can be done from wherever M365 Copilot is available. (Outlook, Microsoft Teams, D365 Customer Service, etc.) To enter the configuration chat, you need to ask Service agent to ‘Enter Maker Mode’. Don’t worry, this doesn’t mean your customer service users will be able to configure the agent. Only users with the prvmsdyn_ServiceAgentMakerCustomize Dataverse privilege for the msdyn_agentmetadataoverride elastic table. will be able to configure the agent. Once you access ‘Maker Mode’ there are 3 different scopes you can configure:

Organization applies all the configurations across the entire organization.
Application Profile applies all of the configuration to a specific app profile
Personal only applies the changes for the logged in user.

There are several configuration options available, makers can configure the case view that appear in the agent by adding, removing, or reordering columns and/or changing the sort order. Forms can also be configured, makers can show or hide certain fields, recorder sections, make fields required or make fields read only. Or, and this is what I would probably prefer, we can define the default form that opens for a specific table. I feel like that would be less configuration vs having to tell the agent to hide/show fields on existing forms etc. but that’s just my personal opinion. Makers can also limit the option set values CSRs can choose from in an option column and we can control the rows that users can select in a lookup field!

Another great configuration option is the ability to restrict the tools that are available in the Agent. If you’ve read my previous article then you are aware that the Service agent has several built-in tools from several MCP Servers. The ability to restrict certain tools allows maker to show or hide them, configure their default availability and override tool settings by profile. This means that different users can have access to different tools and access to those tools can be configured by user profiles.
Another area we can configure is the timeline experience. The timeline helps CSRs understand a customer’s history by bringing together relevant activities in one place. With the Service Agent, we can configure which activities appear in the timeline and control the order in which they are displayed. For example, maybe you only want to show emails and notes, while hiding phone calls, and you might want to configure the timeline to display the newest activities first so CSRs can quickly find the most relevant information without having to scroll through older and maybe less relevant interactions.

Name Spaces

One of the concepts you’ll come across when configuring the Service Agent is something that is called namespaces. Think of a namespace as a way to organize and control which tools are available to a Customer Service Rep. Instead of giving every CSR access to every available tool, a namespace groups together only the tools that are relevant for a specific role or function.
For example, the Service namespace includes tools that are only related to Customer Service, while sales or field service tools stay hidden. This prevents the Service Agent from using tools that aren’t relevant. If needed, makers can configure a namespace by adding tools from other namespaces, giving the agent access to exactly what it needs. By default each namespace has its own set of tools, but we’re not limited to those. By entering Maker Mode, we can view every available tool, (including those outside the current namespace) and choose which ones should be accessible. To add a tool to a different namespace you’ll simply have to ask the Service Agent to add it by saying something like: ‘Add ServiceMcp_get_case to the Sales namespace.’ or ‘Add SalesMcp_leads to the Customer Support application profile.‘
This flexibility allows makers to tailor the Service Agent to their organization’s unique processes. Rather than being restricted to the default toolset, you can create a more specialized experience by exposing only the tools your CSRs need and even mixing tools from multiple business areas when it makes sense.
To check the changes you’ve made, you can simply ask the Service Agent to display the changed in the current conversation. If you need to reset all changes back to default you can do that by using the ‘Reset the configuration to default’ command. Once you have finished with the configurations, you can return to the ‘normal chat’ and leave maker mode, by entering ‘Exit maker mode’ in the chat.

Extending Service Agent

Makers can extend the Service agent either by connecting it to custom built Copilot Studio agents and/or connecting it to non-Microsoft MCP servers. Makers can simply use the prompt ‘Add Copilot Studio Agent’ to start the process. You can ask to browse published agents, or you can provide identifiers manually by entering the Agent ID (Bot ID) and the environment ID. (Make sure to validate connectivity, the agent metadata and verify authentication. Also don’t forget to add an agent description, this is used by the Service agent’s orchestrator to determine when to use the Copilot Agent. When you connect the Service Agent to a (published) Copilot Studio agent, the service Agent can invoke the custom agent’s capabilities to help customer service representatives complete specific business processes, allowing makers to tailor the experience to their organization’s needs. You can easily add, update, or remove these Copilot Studio agents as your requirements change. In addition, if your organization uses non-Microsoft MCP servers, you can connect these to the Service Agent as well. MCP server connections can be registered, tested, updated, or removed, giving makers complete control over how the Service Agent is extended. I hope you enjoyed this article! Be sure to check in again soon for a new one, or subscribe to never miss another post!