We can make use of copilot to summarize the cases. It applies to cases that are canceled and resolved also.
To enable it Navigate to the Customer Service admin center >> Agent Experience >> Productivity >> Summaries (Manage)
Check the Make case summaries available to agents option and save the setting.
Now when we open a Case record, we can see the Case Summary card added, collapsed by default.
We can expand it to see the summary generated.
We can copy it, regenerate it, provide feedback etc.
The case summary considers key Case details like Case Title, Subject, Priority, Case Type, Description, Product, Emails, and Linked Notes as shown below.
The agents can quickly get the required details from the case summary instead of going through all the key fields, emails, and notes associated, thus allowing them to resolve the case quickly.
Copilot (preview) for Dynamics 365 Customer Service provides the following features –
Case Summary
Conversation Summary
Ask a question
Write an email
Draft a chat response.
To enable it, navgiate to Customer Service Admin Center >> Agent Experience >> Productivity >> Manage (Copilot help pane and Summaries)
Check the required Copilot help pane settings and save.
Similarly for Summaries
For geographies outside the United States, to enable the Copilot features for Customer Service, we need to send an email to d365_csaipreview@microsoft.com with the Organization ID to enable the preview.
We can get the Organization ID from the Power Platform admin center for the environment.
As our environment was in the Australia region, we followed the same and within the next day, we got a response from Microsoft that it had been enabled in our Environment.
As per the email, the next step is to Enable copilots and generative AI features outside the US and Switzerland, for this again open the environment in the Power Platform admin center, and select Edit for Generative AI Features.
Check the Move data across regions option and enable it. (We need Global Admin or Power Platform admin role to enable it)
Once we have followed the above steps it adds the Copilot help pane in the Customer Service Hub app.
Similarly, for the Customer Service Workspace app, we can manage it in the corresponding Agent Experience profile.
Navigate to the Agent Experience >> Workspaces >> Manage (Agent Experience profiles)
We can see the Copilot AI features section (below is the out-the-box Customer Service workspace – default profile), we can accordingly update the corresponding agent experience profile(s) records configured/used for the agents.
Below we can see the Copilot help pane in the Customer Service workspace app.
Enabling Microsoft Team chats inside Dynamics 365 allows the agents/sellers to start a new chat from a record or connect an existing chat to a record from within the application itself.
We can enable it from the Power Platform Admin Center or the corresponding Sales, Customer Service, Marketing, and Field Service applications.
Inside Power Platform Admin Center – Navigate to Environment >> Setting >> Team Integration Settings
We can either enable it for all the Dynamics 365 Apps or specify the apps.
Here we have specified the Customer Service Hub and Sales Hub.
We also have the option to specify the record types for Teams chats.
Let us open a contact record inside Sales Hub to see it in action.
We can see 2 sections on the Team chats pane, Chats connected to the record and Other chats.
As we have not connected chat currently, we see the option New connected chat to connect the record to the team chat.
The Other chats section lists the top 200 chat conversations on the Team, from where we can select any conversation to connect it to the record.
Clicking on the New connected chat allows us to search the Participants whom we want to chat with, update the chat name (suggested), and include a note as well.
It also suggests the participant (as the record is owned by a user, it will suggest the name of the record’s owner)
We can also select a user from the Other chat section, and select the Start a connected chat option, which populates the participant.
We can also have multiple participants added.
Add the required details and click on the Start chat
We can see the chat window opening with the participant selected and details / message added.
We can also connect other chats to that record using the Connect to this record option.
We can also disconnect the chat using the Disconnect form this record option.
Similarly, we can also start a regular chat (not associated with any record) using the compose icon in the Teams Chat panel.
This opens the New chat window as shown below.
As we saw earlier, we can use the + Add record types option to add more record types to connect to Teams Chats. (including custom table)
For each record type added, we get the following settings.
Here we can specify who can join and disconnect the chat.
We can also specify if the record’s title can be used for the Chat name, should the note be included or not, and which view fields to be considered for the Message.
We can use the tag parameter in the request to pass any additional information to the plugin. This is added as a shared variable to the plugin execution context.
Below we are creating a lead record and passing the tag parameter in the CreateRequest
And below is our plugin, that gets the tag parameter passed from the shared variable collection.
We can see the value of the tag parameter in the trace log.
Below is an example of where we are passing it in UpdateRequest
The trace log –
Also, the tag parameter is immutable, once set from the API, its value cannot be changed.
Below we had the same plugin registered in pre and post-operation, and we were getting the same value for the tag passed during the create request.
As per the Microsoft documentation, we can use this field to pass any additional details from the client application, that we can use to apply specific logic in the plugin.
In the previous post, we saw how we can use the SuppressDuplicateDetection parameter to throw errors in case of duplicates when creating or updating a record.
Here instead of relying on exception, we can make use of the RetrieveDuplicatesRequest message to detect the duplicates.
Let us take the “Leads with the same e-mail address” duplicate detection rule to see it in action.
We can see 3 lead records already existing in the system with the same email address.
Below is our code that is trying to create a new lead record with the same email address and using the RetrieveDuplicatesRequest to check for the duplicates.
Below we can see that not only do we get the total number of duplicates found, but we can also get the details of the duplicate records found.
We can make use SuppressDuplicateDetection optional parameter of the Request if we want the configured duplicate detection rules to run and throw an exception while creating or updating the record.
We will use the below out-of-the-box duplicate detection rule, that checks for lead having same email address.
Below is our code and we can see the lead records with the same email address getting created without any exception.
Now we have updated the code to use the SuppressDuplicateDetection optional parameter. We have set it as false.
As expected this time we get the exception.
“The record was not created or updated because a duplicate of the current record already exists.”