Fairly recently I created a post explaining the concepts of agent scripts and macros within Omnichannel for Customer Service, in that post I also introduced the concepts of slugs. A “slug” being a replacement parameter which allows us inject data parameters into macros etc. Slugs can be really useful to help you personalise how an agent operates, in this post I will expand on the concept of slugs.

So having created my initial test macros I wanted to experiment to see what slugs are available and therefore help me understand how they might help my agents.

I found this page in the Microsoft documentation for Omnichannel for Customer Service, it explains the concept of the “automation dictionary” which uses slugs to insert data parameters into an “action”.

There are various “groups” of data parameters I can access, below I will document the results I achieved in my testing for each set of data parameters.

In a previous test I had created a marco to create a case, I decided to use this. My idea being to add various “slugs” into the description of the case to experiment with the art of the possible. You can find my post on how to create the macro I used in my testing here.

Pre-conversation Survey Details

I have already created a pre-conversation survey with three questions. Those being “Name”, “Email” and “Question Type”. It might be really useful in an agent script or macro to be able to use these values. For example automatically populating the question type into my case title might be a nice touch.

The format for a slug to display the pre-chat survey data is “${<question name>}”. So in my case “${Name}” etc. Below you can see that I have added the required values into my macro to create a case.

Having saved my updated macro, I started a conversation. See below how I entered the required answers into my pre-chat survey.

Below you can see the agent’s experience for this conversation. They have used my test “Create Case” agent script / macro. You can see that the details from my pre-conversation survey have been automatically added to the description on my case.

Productivity slugs

Having had some success with populating details from my pre-chat surtvey my mind turned to what other information might be useful …. We actually have a whole set of values which might be useful in macros / agent scripts. Including customer name, language and more.

So this time I added the following into my description field in my macro.

PRODUCTIVITY SLUGS

CustomerName = ${customerName}

CustomerEntityName = ${customerEntityName}

CustomerRecordID = ${customerRecordId}

QueueId = ${queueId}

VisitorLanguage= ${visitorLanguage}

VisitorDevice= ${visitorDevice}

entityRoutingLogicalName=${entityRoutingLogicalName} (Only with entity channel!)

entityRoutingRecordId=${entityRoutingRecordId} (Only with entity channel!)

customerEntityName=${customerEntityName} (Only if visitor is authenticated)

You can see below that this time my case description contains the customer name and other details. I didn’t (in this test) get any values returned for fields like entityRoutingLogicalName. As those would only be populated if I was working with the entity channel. (I was in a web chat session!)

Anchor and Current Tab

Next I turned my attention to grabbing the entity name and ID of the record in my anchor tab or the current tab.

NOTE: Unfortunately I had less success with this option. But I have documented my experience as this may work in later releases. Or maybe someone can point out my mistake!

You can see below that I have added data parameters that I hoped would return the name of the entity and also the ID of the record. This could be useful if I then wanted to query data for that entity. (see OData later in this post!)

For the anchor tab, for example I entered …${Session.AnchorTab.entityName} and ${Session.AnchorTab.entityId}. Unfortunately I only managed to make this partially operate. The entity name was returned but not the ID.

I will return to this later! And if I find a fix I will update this post.

OData

My next test was with OData. As if I could query data CDS this could significantly expand what I could achieve in my macros. The syntax for the OData query is …. “{$Odata.<entityName>.<entityAttributeName>.<?options>}”

I wanted to return the name of the account asscociated with my conversation. So, as an example, I added the following into the description field in my macro.

Account Name = {$Odata.account.name.?$filter=accountid eq ‘${customerRecordId}’}

Now when I run my macro the account name is populated into the description. I could of course query different data as required!

FYI: I did find one minor issue. I could have multiple OData queries populating various fields on my case. But I found the macro would fail if I included two OData queries in a single field.

Conditions

Next I wanted to see what else I could do with the slugs in my macros. One option might be to use the data parameters in conditions.

I could (for example) decide to create a case with different values based on the type of query. In fact maybe my condition might decide if a case or a lead entity is the right thing to create etc.

Another useful example might be to create a case differently depending on the customer associated with the conversation being a contact or an account. Maybe I’d include different OData queries then based on the customer type!

So I wanted to create a simple example of using slugs in conditions in my macro. I have a very “poor” example below. If the name someone entered in my pre-chat survey contained the word “Parkhurst” then I would open a relevance search populated with that value.

I recognise this isn’t the best example in the world but I hope you can see that the using slugs in condition and other actions within macros could be really powerful.

My tests weren’t 100% successful but they were very pretty close. I did have to spend time experimenting with exactly the correct syntax to use but now I have done that I can see that using slugs in macros has some exciting potential applications. So if you are using Omnichannel for Customer Service I suggest you experiment with them as you should be able to create some really cool automatons. Enjoy.