NEIL PARKHURST

As I revised for the MB2-718 exam (Microsoft Dynamics 365 Customer Service) I’m creating blog posts detailing all aspects of my revision. I hope these posts will aid anyone who is also revising for this exam. In this post I will continue to explain the concepts around Unified Service Desk (USD).

My blog is full of information about Unified Service Desk! So much so that I believe you can explore my blog and find everything needed to learn about USD!! One good starting point might be what I call “USD – The Book”. You can view it here.

In previous posts I have covered some of the key concepts and terminology. Plus details relating to the sections of the skills measured statement including; “Install and Configure the USD Application” and “Implement Hosted Controls”. In this final post I will cover the section entitle “Configure Server-side Synchronisation”. This portion of the skills measured statement is shown below;

Configure Server-Side Synchronization

I am a little unsure why this section is given this name! As the details don’t seem to mention anything that I would class as server-side synchronization, but regardless lets review the detail for the points mentioned!!

USD Sessions

In USD we can have global and session based tabs. (Hosted Controls.) Global tabs are, as the name suggests, global and not linked to any session. A session is simply a collection of related tabs. Session tabs are used to allow users to quickly navigate between each collection of tabs within the session.

This is an extremely useful concept in contact centres! As often agents will need to juggle multiple customers at once. Typically each session will relate to each customer they are working with. The session would then contain multiple tabs, including the contact/ account in question, the related phone call activity plus additional tabs including relevant cases, opportunities and such like. This approach allows agents to view large numbers of “CRM” pages and also external data quickly and in context.

To understand just how useful this is try imagining handling web chat conversation with 5 customers at once. (As can happen in a contact centre.) For each customer you might open at least their contact, account, an activity record and a case. Without USD you would quickly have 20+ browser windows open. And all being unrelated you’d need to repeatedly tab thru them to find the form you need to update. But with USD and sessions this task can be completed effortlessly.

As an example I have shown my USD system with two sessions open. Notice that each session is given a name and additionally each session can have an overview. (I will explain more about these soon!!)

When we need to create a session several things come into play. Firstly your hosted control must be session based. Or phrased another way it must not be a global tab! Below you can see I have a hosted control called “Account”. This will hold my accounts when displayed within a session and therefore the option “Application is Global” is not selected.

Next we use session lines. These have two purposes. One is to name the session name and the other is to provide the session overview. Below I have shown y session line used to name my account tab. Notice that the type is “Session Name”. Also that this session is linked to the account entity. Meaning this will be used each time a session is started containing an account. You might also notice that in the “Display” field I have used a scriptlet. We haven’t covered scriptlets yet! A scriptlet is simply some JavaScript that will return something. In my case it will return the name I want to display for the session. If you don’t use scriptlets when name sessions you can simply type the session tab name. (For example you could enter something like “Account – [[account.name]]”.)

Tip:
Session names do have a order. One way you can use this is by having a session name with a high order that doesn’t have an associated entity. Meaning that would then effectively become a default name for any sessions opened for entities you have specifically referenced.

Session overviews may look slightly more complicated but the concept is simple enough. Like session names, session lines for your overview will have a type. So “Session Overview Line”. And they can also be linked to an entity in a similar way as with session names. The display field then contains some xml which will be used to display the session overview.

Finally and importantly we use window navigation rule(s) to decide when to create a session. I cover the concepts behind window navigation rules in part three of this series of posts. So I won’t repeat those concepts. But you need to be aware that there is a “special” action type on window navigation rules that can be used when you want a new session to start. Below you can see the rule I use for opening an account session. If you open an account entity and that is done from my search tab, an account will popup. When this happens the action that will be triggered will be create session.

User Settings and Options

User settings and options are often used in similar ways but they have a few differences. Both can be defined in the USD settings and both are name / value pairs. Meaning I have a “variable” and it has a value.

Let’s consider options first. Options are global constants. By describing them as a constant I mean they are not changeable at runtime. These are really useful to define a replacement parameter that has a fixed value. Its value can be set in options but then references in actions (etc) throughout USD. You do this using the $Global reference, for example [[$Global.MyOption]g]. (Tip: adding the g to the replacement parameter simply denotes it is a global value.)

Some global options have specific meanings and are predefined with USD. You can find details of all the system options here. But to give you just one common example, there is an option called “maxNumberOfSessions”. This will limit the number of sessions a user can open at once. The default is 5 sessions but often I have seen a lower setting be used to reduce the load each agent can make on Dynamics 365.

User settings are also name value pairs. But they are associated with specific users. Meaning one agent could have a different value to other agents. We reference them using $Settings, for example [[$Settings.MyUserSetting]g]. By way of an example I have shown one of my user settings below. Here I am setting a name of “SystemAdmin” to be “True” for a user called “Neil Parkhurst”. By doing this I can denote which users are admins. (This might then be useful if I want to hide the debugger toolbar button from everyone expect admins!)

I have mentioned that options are constants. Meaning they can not be dynamically changed at runtime. User Settings are not constant. We have two actions “SaveSetting” and “ReadSettings” that allow us to change and refresh options dynamically. Both of these actions are “UII Actions” of your global manager hosted control.

Agent Scripts

An agent script is a simple way to provide a guided process with Unified Service Desk. They are essentially a question / answer matrix. The script will give the question the agent should ask, there are then a list of possible answers. Each answer can trigger a number of actions. For example, a script when opening a contact might prompt the agent to welcome the customer and ask them how they can assist today. Possible answers might include creating a case if the customer has an issue with an existing product or creating an opportunity if they have a sales query.

Before we can create the actual agent script you will need to create a hosted control with a component type of hosted control. Notice that the display group is WorkflowPanel. This is the “special” area of the screen reserved for agent scripts. (Tip: Technically you can display agent scripts in other panels but you may find they don’t look as good as in their intended location!)

Having created our hosted control we can create the agent script. Using the agent script option you will find in the settings area of USD.

Below you can see an example agent script. Notice that you have two fields “Script Text” and “Instruction”. These will effectively hold the script / question that you wish the operator for follow. Then below we have a list of possible answers.

Tip: Notice the field called “Start Task”. Setting this to “Yes” will mean this script will start each time a session starts. Alternatively you can trigger an agent script using a GotoTask action. (I’ll describe that in a second.)

When you create an agent script answer you define its name and order. Then you can associate one (or more) actions that will be triggered when the script is selected. Additionally you could add conditions to define when the answer should be visible and (or) enabled.

I have already mentioned that some scripts can be triggered because they are start tasks. However sometimes we need to trigger the start of an agent script from an event. Such as maybe you want an agent script to help with case resolution to start each time a new case is created. Or maybe one agent script answer can trigger the start of another agent script. Below you can see an example GotoTask agent script action. These simply need to have the name of the agent script you want to trigger in the data field.

Debugger

I have already mentioned the debugger in a previous post in the series. But the debugger is mentioned twice in the skills measured statement! This time the specific reference is “identify debugger components and capabilities, view page data and parameters“. So lets look at the debugger to try to understand it in more detail.

Note: The debugger is a really important tool whilst developing a USD application. You should therefore spend quite a bit of hands-on time to get a really good understanding of how it works. This post on the debugger might help get you started.

Action Calls / Debug Output

As already mentioned spending time becoming familiar with the debugger is really important! The tab I use the most is “Action Calls”, here you can see all actions / events in the order they were triggered. Any actions which failed to meet the condition for them to run will be coloured yellow. Any that fail due to an error will be coloured red. (You might need to find and fix those!)

If you select any of the actions and use your mouse right click a menu will display which allows you to copy the actions, replay it or even edit it.

Additionally the “Debug Output” tab may provide you with additional technical debug information about the actions.

Data Parameters

I have already described replacement parameters. Within the debugger we can see and interact with replacement parameters. Below you can see how the debugger has a data parameters tab. Here we can see the replacement parameters. Notice that some are marked as “(global)” whilst others are not. Those not marked a global refer to the currently open session.

We have several icons in the toolbar of the debugger for data parameters, below I will describe the function of each.

The Refresh icon is really important. When you view the data parameters in the debugger they may not be showing the current state. Clicking this refresh button will update all of the data parameters.

We then have two copy icons. The first will copy the name of the selected data parameter. So in my example above it would return [[Contact.address1_city]], the second returns the content of the parameter. So in my example the value “Birmingham” would be retured.

The next icons allow me to edit or create data parameters.

Direct Actions

In addition to viewing actions that have been run, we expand a panel that allows us to select and run actions.

Importantly we also have the “Direct Action” tab. In here it is possible to create new actions and run them. (Or edit existing ones.) There is even a save icon, which will allow us to save the action to our USD configuration should that be required.

Hopefully this fourth post relating to Unified Service Desk has completed my overview addressing the skills measured statement in the MB2-718 exam. It this point I hope you have a good understanding of the basic capabilities of USD. I would like to stress that I have no knowledge of what questions might come up! So I encourage you to dig deeper into all of the topics I have mentioned. You may find you enjoy it!!!