With Microsoft’s Omnichannel for Customer Service I recently had a requirement to create one or more categories for each conversation. The idea being that agents could categorize conversations to support various reporting requirements later down the line.

In some scenarios the case table is used extensively. If so, I normally turn to that to understand what type of queries were logged from what conversations.

But not everyone uses cases! And also, maybe you have multiple conversations in connection with one case and want to categorize each one separately. For example, a customer might initially have a web chat conversation to log a new support request. And then might later phone up to complain that the case has not been resolved. I might want to report the first conversation as a “New Request” and the second as a “Complaint”.

I found a couple of challenges with this requirement! Firstly, you cannot add columns directly to the out of the box conversation table. Secondly when a conversation is live in the customer service workspace the form we use is called “Customer summary”. I found that customization options on this form were limited. As far as I can tell the reason is because the form is always in “create mode”. Even though we are editing a conversation record! Meaning simply adding a sub grid or lookup onto the conversation table where not options I could use.

My solution was to create a custom table to hold my categories, then to link that table to the conversation entity. Next, I created a macro and agent script to quickly create the category records. And finally, I showed the data on forms / charts etc.

In this blog post I will explain the details of my change … These notes will be pretty detailed, but I am going to assume you have a basic knowledge of Dynamics 365 and the Omnichannel for Customer Service app.

Step One – Create custom entity

My first step was to create a custom entity that will hold my category and be linked to the conversation table. I called my table “Conversation Category”.

I just added two custom fields to my table.

The first was a look up to the conversation table. I called that “neil_conversationid”.

The second was a choice (pick list) that contained the possible categories I wanted to apply. In my example a choice field was fine, but you could use a look up to a table or a text field if you’d prefer.

In my choice field I had options like “New Customer – Sales Query”, “Existing Customer – Complaint”. You could obviously add whatever categories make sense in your situation!

Once I’d created my fields, I created a simple form. There was only one field the user could edit, that being my choice field.

Although I did decide to show the default primary “name” field and the lookup to the conversation on my form. But as the agent shouldn’t amend either of these fields, so I made them both read-only.

My final change was to create a view. This was a mega simple view that had just one column. (My “choice” field.)

I will explain where I used this view later in this post.

Step Two – Macro / Agent Script

Next, I wanted the agent to be able to quickly create a category record. But as already mentioned I couldn’t “just” add a sub grid to the out of the box customer summary form. So instead, I decided to create a macro that could be triggered from an agent script. The macro would be used to open a “conversation category” form and link the category to the current conversation.

My Macro was simple enough! It just had one action to “open a new form to create a record”.

In this action I just added the logical name for my conversation category table. Mine was “neil_conversationcategory”.

Next, I needed to supply some text for the name field on my table. As that is the primary / mandatory field.

I added “Conversation Category for ${Session.AnchorTab.entityId}“.

Tip: ${Session.AnchorTab.entityId} is used to return the GUID of the record in the anchor tab. In my example that will be the web chat or voice conversation record that triggered my session to open.

Next, I needed to link my conversation category record to the conversation. My lookup field was called “neil_conversationid”. I needed to set that to the GUID of the conversation. I also needed to provide the type of entity for the lookup and a name.

So my “neil_conversationid” attribute was set to ${Session.AnchorTab.entityId}.

I didn’t have a name! But I set my “neil_conversationidname” attribute for “Current Conversation”. The correct name would show once I clicked save. So, I didn’t really care what the name was! (Tip:
I have just added “name” to the end of my lookup field name to achieve this!)

Finally, I need to set the type of table. So I set “neil_conversationidtype” attribute to {Session.AnchorTab.entityName}. As that would return the schema name for the conversation entity from my anchor tab. (Tip:
I have just added “type” to the end of my lookup field name to achieve this!)

My final step was to create an agent script step that would trigger my macro.

Step Three – Form Changes

My next step was to show the category data on the conversation form.

As already mentioned, I cannot amend the “Customer Summary” form on the conversation table. But we have two forms available!

“Customer Summary” is displayed whilst the conversation is active. But when we later review the conversation the “Conversation Form” is used. I could add a sub grid to that form.

Below you can see that I have added a section header “Categories” to the form. And then added a sub grid.

Tip: When you open this form in the form editor you might not see any tabs, fields or anything! This is because most fields are hidden by default. Clicking the “Show Hidden” option will solve that problem!

As I added the sub grid to the form … I selected the option to only show related records. I then picked my table, “Conversation Categories”.

And finally, I selected the view I’d created earlier, I’d called this “Categories (Conversation Form)”. If you recall this view is really simple including just the category field, meaning my grid will simply show a list of categories.

Step Four – Dashboard

My final step is optional! And you may decide to achieve this differently to me. (So I won’t go into great detail here.)

I created a very straight forward dashboard that would show a count of how many times each conversation category had been used. This was added to a simple dashboard I have created that shows the number of conversations each day by agent, queue, sentiment etc.

You could do something similar or maybe even something much better using Power BI!

In Use ….

Below (as an example) I have shown how my solution operated. I have an agent script called “Create category”. Clicking this opens the category form where the agent can pick the required option.

In the end this change was simple! But it did help me address a requirement that I think will be quite common in many Omnichannel implementations. So hopefully seeing how I achieved this may give you some ideas on how you could apply this to your solution. Enjoy!