編輯

共用方式為


Route or deflect cases using AI Builder

Applies to: Dynamics 365 Customer Service

Case management is the core of any customer service solution. Dynamics 365 Customer Service offers many features to collect customer support inquiries, track them as cases and allow agents to work on a resolution.

In particular, when working with Omnichannel for Customer Service, it's common to receive requests from multiple sources. Some of these channels imply a direct interaction with the customer (such as chatbot, direct call) and therefore allow the collection of detailed information through scoping questions. However, other channels are asynchronous in nature, such as emails.

Working with unstructured data, as emails are by nature, may take extra effort when processing the resulting case, in order to achieve the following objectives:

  • Analyze the original message
  • Define the nature of the request
  • Understand how the case needs to be assigned and resolved

Email-to-case process with automatic record creation and unified routing

Let's consider a typical scenario such as in the following illustration:

Diagram of Omnichannel for Customer Service, showing the route that begins from the mailbox.

Many organizations have a support mailbox (such as support@contoso.com) which external contacts use to forward their support requests.

When this mailbox is associated to a queue in Customer Service, and the queue is configured to convert incoming emails to activities, every new incoming message is created as an email activity and registered as a queue item.

Screenshot of the Email settings screen showing the Convert Incoming Email to Activities field.

By applying rules to automatically create or update records, these activities can be transformed automatically into new cases.

Screenshot of the Step 1 details pane, showing the rule name, queue to monitor, and activity type to monitor fields.

Screenshot of the Condition pane, showing the condition name and condition that must pass fields.

Screenshot of the Actions to take field, showing the Record to create and Configure in Microsoft Power Automate fields.

Then, by setting up routing of records, the newly created cases can be delivered to agents for resolution.

Since the case description was populated automatically with the email body, the actual request for the case could be hard to identify. Also, the customer could be sending the request to a wrong mailbox (such as a support request to an "info" mailbox).

For cases originating from emails, the organization may then need to have one or more agents dedicated to manually sorting through those cases, to triage and categorize them, and eventually route the request again to assign it to the proper owner.

This could require a significant effort in dedicated resources, and it might be a good idea to apply some automation in this scenario.

AI capabilities in unified routing

With unified routing, you can apply machine learning model-based rules during the work classification phase:

Screenshot of the Create work classification ruleset screen, with the Machine learning model rule type highlighted.

While these are powerful options at our disposal, there are still a few scenarios that might not be covered:

  • There's currently not an option to invoke another model—for example, a custom model.

  • The work classification rules are applied at workstream level. There isn't an option to apply machine learning at an early stage—for example, before the routing actually takes place.

Note

Always check the product documentation and roadmap to be aware of all the latest available features.

Power Automate and AI Builder

When you set up the different types of automatic routing, you'll see the link Configure in Microsoft Power Automate. Modern routing actions are implemented as Power Automate flows. The automatically generated flow has some predefined steps, such as recognizing the email sender and create the case record. You can edit the flows to add more steps, such as the step added in the following illustration:

Diagram showing the progression of the Power Automate flow.

Note

Some of the predefined steps are restricted for editing. Changing or moving these steps in unsupported ways could prevent the routing from working properly.

An existing capability in Power Automate is that you can use AI Builder models in a flow.

AI Builder offers many prebuilt models: sentiment analysis, category classification, language detection, entity extraction, and more. It's also possible to create and train a custom model.

Better email-to-case process with AI Builder

By applying the capabilities of Power Automate and AI Builder, it's possible to evolve the initial scenario:

Diagram of the email-to-case process with AI Builder for Omnichannel for Customer Service.

Adding AI Builder actions to the routing flow, we can analyze the original text of the email, extract relevant information, categorize the case during initial creation, and allow the routing engine to identify the proper destination.

Adding AI Builder actions in routing flows

To demonstrate this approach, we'll start by preparing a custom GPT prompt in Power Platform's AI Prompt section:

Screen of the custom prompt editor in Power Platform.

Screen of the custom prompt editor in Power Platform with detailed prompt.

The flexibility of the GPT prompt lets us define that we want to process an input text and ask to categorize the text in one of our predefined categories. We can also specify that we want a text field containing a reason to justify the assigned category. To complete the prompt we ask to extract additional information from the text. We can also indicate that we want the output formatted as JSON and include an example of the desired data structure.

We can test our prompt directly from the editor by providing a sample input text to observe a preview of the output. This allows for some fine-tuning before saving the finalized prompt.

We're now ready to use the newly created prompt in our existing ARC flows, to implement the following logic:

  • Process the text of the incoming email
  • Identify the category of the request
  • Store the extracted information in the new case

Before proceeding, we need to define some new columns in the case table to store the values returned by the AI model:

Screenshot of a list of custom Dataverse columns.

It's also a good idea to add these new columns to the case form, so we'll be able to see their values during our test later.

Now that the data model is ready, we can start editing the flow in Power Automate. We want to position our new steps just after the check on the email sender, and right before the case creation:

Diagram of the Power Automate flow, with the cursor highlighting the Insert a new step option.

When adding the new step, we start by selecting the AI Builder connector to filter available actions, and then select the action Create text with GPT using a prompt:

Screenshot of Power Automate AI Builder connector.

Screenshot of Power Automate AI Builder actions.

In the configuration of the new step, we need to select our previously saved custom prompt, and pass the Description value from the incoming email as the input parameter:

Screenshot of Power Automate AI Builder step.

Since we instructed the prompt to return a JSON output, we add an additional step to process the JSON that will allow us to work with specific fields. To do so, we leverage the native Parse JSON action, and provide a sample of the expected JSON to generate the corresponding schema:

Screenshot of Power Automate Parse JSON step.

Finally, we can use the extracted values in the existing step that will create the new case:

Screenshot of Power Automate create record step.

With these changes, the ARC flow will perform the expected logic to transform an incoming email into a new case, but at the same time it will enrich the case with the results from the AI action.

Testing the process

Now that we have implemented all the changes, we're ready to perform a test. As a prerequisite, we must correctly configure server-side-sync on a mailbox associated with the queue where the routing rule triggers; otherwise, we won't receive any emails.

Let's compose a new email, simulating the feedback from a dissatisfied customer, and send it to the queue we configured:

Screenshot of an email to customer service informing them of a damaged product and requesting a new keyboard or refund.

After a few minutes, we can see that the mail is synchronized in Dynamics 365 and registered as a new activity:

Screenshot of the feedback on product email, showing the sender and recipient of the email.

Let's check our Power Automate flow and we'll see it was correctly triggered:

Screenshot of the 28-day run history pane, showing the Start, Duration, and Status fields.

If we open the details of this execution, we can check the results of the GPT prompt:

Screenshot of the Outputs extendable pane, showing code that reveals the status of the GPT prompt.

Finally, going back into Customer Service to see the generated case, we can see the values stored in the record:

Screenshot of the case form in Dynamics 365, showing the AI fields being populated.

With these values, we can enter the configuration of the workstream, and define new routing rules to divert the case to a specific queue, based on the predicted category:

Screenshot of the Conditions pane, showing customizable fields to configure a workstream and define routing rules.

Even if you don't want to implement complete automation in your routing rules yet, and prefer to let your agents analyze incoming emails, you can greatly reduce their effort during the triage phase by providing a suggested category and a simple explanation.

Working with custom categories

In the previous example we provided a static list of categories in the definition of our prompt. But what if we want to define and maintain the categories in a Dataverse table? Let's say for example that we created an Email Category table to list the category values and insert a description of the category:

Screenshot of the Email Category table in Dataverse.

The GPT prompt editor allows us to perform grounding on Dataverse data, so we can edit our prompt to add a reference to our Email Category table, specify that the incoming text has to be matched with the category description and that we want the corresponding category name in return:

Screenshot of the GPT prompt editor with Dataverse grounding.

The results of this prompt will be very similar to what we obtained previously, but this time if we need to update the list of our categories, we can simply change the records in Dataverse and no change is required to the prompt definition.

This approach also allows us to build some kind of fine-tuning and continuous improvement process. In this example, we have users check the results of the automated email categorization, and confirm or change the assigned category. For that purpose, we implement a flow with steps as in the following list:

  • Add in the case two columns, one for AI Category and one for Confirmed Category.
  • Let predefined user roles double-check the category assigned by the AI.
  • Users can confirm whether the assigned category is correct, or select a different one.
  • Periodically extract all the records where Confirmed Category is different from AI Category.
  • Analyze the list of records to understand what they have in common and why they were assigned a wrong category.
  • Improve the descriptions of the affected categories to improve the accuracy of the AI model.

With a process such as this example, you can incrementally increase the accuracy of your flow, without the need for any change to your implemented solution. You could even try to use a GPT prompt to generate category descriptions starting from past resolved cases.

Dataverse AI Functions

Another option you can evaluate is the use of Dataverse AI Functions instead of the GPT prompt:

Screenshot of Dataverse AI Functions in Power Automate.

These functions are exposed as any other unbound action. You can easily run them not only from your Power Automate flow, but also in low-code plugins. While offering a bit less flexibility because you can't formulate your own custom prompt, they represent a very simple way to perform some AI actions in your solution.

Summary

This article takes you through how a low-code approach can help you enhance a typical email-to-case process with the addition of AI automation, and enhance and simplify case routing.

AI Builder offers many capabilities, and opens the opportunity to achieve interesting results when used in combination with Customer Service.

We could, for example, implement a flow recognizing customers requesting instructions to reset their credentials, and generate an automated response with a link to a KB explaining self-service procedures.

Again, we could implement a flow to detect a customer asking for the status of a shipment. The flow could extract the unique number of the shipment, call an external API to check the status, and provide an answer to the customer automatically, resolving the case without human intervention.

With the flexibility of the GPT prompts, and all the tools offered by AI Builder and Azure Open AI, you can build exciting solutions that work seamlessly in your Power Platform environment.