Skip to main content

Notifications

Unified Routing – Preferred Agent Routing (and Agent Scripts)

Neil Parkhurst Profile Picture Neil Parkhurst 10,725 User Group Leader

When we are using Omnichannel for Customer Service we can use Unified Routing to assign conversations to a contact’s preferred agent. This is a useful approach to give a personalized experience to customers. But I’ve always had a concern about the amount of maintenance required to assign a preferred agent to each customer. In this post I will try and address that concern …

The link to my previous post on how to configure this feature is below.

Unified Routing – Preferred Agent Routing | Microsoft Dynamics 365 (neilparkhurst.com)

In this post I plan to focus on how I’ve tailored my system to allow agents to “tag” themselves as a customers preferred agent. Meaning that whilst talking to a customer they could select an agent script. The effect of which would be to override any existing preferences and make the current agent the new preferred agent.

I can visualize a few additional ways this requirement could be satisfied! For example, maybe each time a new case is created we could make the owner of the case the preferred agent until the case is resolved. But in my test, I wanted the agent to select an agent script. The agent script would trigger a macro, which in turn would run a Cloud Flow. And that Cloud Flow would make the agent triggering the Flow the preferred agent for the customer.

Below you can see my idea …. Essentially within the customer service workspace. If an agent clicks on the “Make me preferred agent” my automations will run. And then next time the customer calls (on any channel) Unified Routing will try and assign any new conversations to the current agent.

The Steps involved were …

  1. Create an instant Cloud Flow.
  2. Create a Macro to call the Cloud Flow.
  3. Create an Agent Script to call the Macro.

Step One – Create an instant Cloud Flow

The Flow I created (at a high level) is shown below. This was simple enough to created but if I’m honest was a little more involved than I first thought. So I will explain the steps in more detail below.

When a record is selected

The trigger for my Flow is a legacy trigger! As to be able to use the Flow within a Marco it needs to be an instant Cloud Flow based on the trigger “When a record is selected”.

Notice that the table name is contacts. As later my macro will be run against a contact.

Initialize variable (UserGUID)

The reason for this action to initialize a variable will become a little clearer soon! But it is connected with my first challenge!

I wanted to make the user who triggered the Flow become the preferred agent for the contact. We do have the “user id” of the user who triggered the flow. But I quickly realised that is the ID for the user in active directory. But I needed to know the unique ID of the user from the Dataverse. Which is a different thing.

So my first step was to create a variable called UserGUID that will later be populated with the ID of the user in the Dataverse.

List rows (Find users based on triggering email)

Next I have a list rows action which is going to query the users table in the Dataverse.

So my table name is “users”.

Next I filter the rows. I am basically looking for a user whos domainname matches the email address for the user who triggered my Flow.

This was slightly more involved than I thought! Originally I entered my filter as shown below. But that didn’t work!

I copied my filtering line into notepad. Here I could then see what was actually happening. As the field “User email” was ctaully returned an encoded version of the email address.

domainname eq ‘@{triggerOutputs()[‘headers’][‘x-ms-user-email-encoded’]}’

So I simply removed “-encoded” in note[ad and pasted the result back into my filter rows field. You can see how below it was then showing “x-ms-user-email”. This looked a little strange but worked perfectly!

domainname eq ‘@{triggerOutputs()[‘headers’][‘x-ms-user-email’]}’

I assumed / hoped I’d only ever get one row returned. So I also set the row count to 1.

Below you can see that within an”apply to each” control action, I added a set variable action. Here I am setting the variable I initialised earlier to the unique ID of the user returned by my list rows action.

List Rows (Current Preferred Agents)

My next challenge was that I wanted to avoid any potential for duplicate preferred agent records. And also, in my scenario I wanted to only have one preferred agent for a contact at any one time. (Although I should point out that it is perfectly valid to have a list of preferred agents for each contact if you require that!)

So, I wanted to list all of the current preferred agents and delete them.

In my list rows action I selected “Preferred Agents” as the table.

My filter rows basically looked for any rows where the field “msdyn_recordid” contained the GUID of the contact.

_msdyn_recordid_value eq ‘@{triggerBody()?[‘entity’]?[‘contactid’]}’

I then have another “appy to each” action. This time it will be applied to any existing preferred agent rows returned. So within my “apply to each” loop I have simply added a “delete row” action. With the table as “Preferred Agents” and the Row ID of the record returned.

Add a new row (Preferred Agent)

Finally, I finished off my Power Automate by adding an action to add a new Dataverse row. You can see how this looked below.

My table was “Preferred Agent”.

The name field was mandatory, so I decided to show the contacts name in this field. But I could have added other values. Maybe I could have also added the agents name or something like that.

The other mandatory field is “System User”. Here I added the GUID for my user record that I’d stored in my variable.

Then in Record Id (Contacts) I needed to add the GUID of the contact.

The only other field I set was “record type”, As that needed to be “Contact”.

Tip:
Before continuing I tested my Flow by running it as an on-demand Flow against a contact manually. Meaning that I already knew it worked before creating my macro / agent scripts.

Step Two – Create a Macro to call the Cloud Flow.

I was now ready to create a macro. So, within my customer service workspace admin center app, I located the macros option. You’ll find this in the productivity option.

Creating my Macro was simple enough!

It only really has one action, which calls my Cloud Flow. As you can see below, I have added a “Run Flow” action. The table is Contact.

For my “Entity record id” I entered ${customerRecordId} … when the macro is run the GUID for the customer (aka contact) associated with the current conversation will be placed into the entity record id.

Under “Select flow”, you will be presented with all Flows which have the When a record is selected” trigger for contacts. So I simply selected the Flow I’d already created.

Step Three – Create an Agent Script to call the Macro

In the productivity area of your customer service admin center you will find the agent scripts option. I already had an agent script with multiple steps. So I simply needed to create an additional step.

Below you can see that I have opened my existing agent script and used the “+ New Agent Script Step” option to add my “Make me preferred agent” step.

I have shown my agent script step below. You can see that the type is “Macro”. And then I have simply selected the marcro I’d just created in the target macro field.

Despite facing a few minor challenges in creating my Power Automate I found this a simple customization to complete. But one that I hope will be useful to help give a personalized experience to customers.

Having completed this change my original reservations about the maintenance overhead of preferred agents have been eased. Meaning I am now excited to revisit this feature. And maybe experiment with a few different automations to default the preferred agents for contacts. Enjoy.

Comments

*This post is locked for comments