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! I therefore hope that you can explore my blog and find everything needed to learn about USD.A good starting point might be what I call “USD – The Book”. You can view it here.
In part one I explained what USD is and some of the key concepts / terminology. Now let’s start to consider the points mentioned in the skills measured statement ….
The skills measured statement is split into three sections, in this post I will address the first section described as “Install and Configure the USD Application”. Please keep in mind that the notes I provide here are a summary for revision purposes. You will probably need to dig deeper into each topic to gain a better understanding than can be gained from just reading these notes! Having said that I hope this overview gives you a good introduction into the items mentioned in the skills measured statement.
Install and Configure the USD Application
Install and Configure USD
Installing USD is a two step process. First we run a package deployer which will install (or upgrade) the USD solutions within your Dynamics 365 instance. This package deployer can also optionally install a sample USD configuration.
Tip:
Unified Service Desk can be deployed into Dynamics 365 online or on premise.
Below you can see the package deployer running. Notice that I am given several options. Allowing me to simply upgrade USD or install a sample package. If you are new to USD installing the sample package highlighted in blue below is often a good starting point.
After the package deployer has finished you will find a new Unified Service Desk option in the settings area of Dynamics 365. Within this you can define all of the USD components I mentioned in the overview I gave in part one.
Having run the server install you will next need to install a client on the agents desk top.
When a user opens the USD desktop client the configuration appropriate for them will be cached to their PC. Meaning the configuration is held locally but is maintained on the server. When I say configuration I simply mean the data which defines the hosted controls, actions, events, etc that make up your solution.
UII Actions and Action calls
I have already mentioned UII Actions and Action Calls in my overview. When we look at a hosted control you can navigate to an option called UII Actions. Here you can see all of the UII Actions available for that hosted control. (Or create new ones if you need to extend the capabilities of USD.)
Below you can see that I have opened the UII Actions option on a hosted control I use for the accounts tab. Each UII Action will perform a different function when called using an action call. For example the UII Action called “SetUserCanClose” can be used to decide if users are allowed to close the tab (or not).
Notice there is a UII action called “default”. All hosted controls have an least one UII Action, the default action. With custom hosted controls this is commonly called to the load of the hosted control.
An action call is an instance of you needing to fire a UII Action. Each action call is associated to a hosted control and a related UII Action. Then optionally a data field can be used to define how the action will behave. For example, the MoveToPanel action would move a tab from one area of USD to another. (Say from the right panel to the main panel!) The data field on the action call would contain the name of the panel you would want to move the hosted control to. As an example, I have shown a Move To Panel action call below.
Tip: Keep in mind that each UII Action could have different information in the data field. And also that some simple actions may require no additional information in the data field.
When we have a list of actions calls to perform the order field can be used to sequence them. Also each action can optionally have a condition that can be used to define situations when the action call should or shouldn’t run.
Connection Manager
There are several hosted controls which are essential for USD to run, one of these is the connection manager.
The Connection Manager hosted control manages connections to Dynamics 365, making them available to the rest of the unified service desk application. The presence of this hosted control is mandatory! Plus only a single instance of this hosted control type can exist. Implying that your USD configuration only connects to one Dynamics 365 instance.
Importantly the connection manage has no pre-defined uii actions or events!
Global Manager
Another mandatory hosted control type is global manager, this is the core of your Unified Service Desk application. I like to think of it as the container for the entire application. It loads / reads all of the configuration data at start-up, interprets the window navigation rules, provides the toolbar and agent script components plus manages the data for all sessions.
Like connection manager, this global manager is a mandatory hosted control and must exist only once.
Below you can see the standard events available on the Global Manager hosted control. Some important ones include “DeskTopReady” which is triggered when USD loads. And also events such as “SessionClosed” and “SessionNew” which are triggered as sessions start or close.
Below you can see a selection of the uii actions typically available on Global Manager. Notice that my global manager as 58 pre-defined uii actions, so there are quite a few! You may want to refer to Microsoft’s documentation to review a few of these!
Debugger
The debugger hosted control allows us to debug the USD actions / events. Its presence is optional. (Although I always have a debugger configured!)
Commonly you will create an action call that uses the debuggers default uii action to load it. (Often this action will be called from a toolbar menu button.)
Below you can see what the debugger looks like once loaded. It gives you details of all events / actions that have been run. Plus highlights any actions that failed to run. (Either because a condition wasn’t met or if the action gave an error.)
But as you will see in later posts you can do much more with the debugger. Including running actions directly in the debugger. Something which is really useful when you are experimenting with something new!
The skills measured statement mentions that we need to understand how to use the debugger. I will therefore return to explaining it in more detail in a later post.
In my next post I will cover the next section of the skills measured statement which includes implementing hosted controls, including toolbars, events, data replacement parameters etc. So lots to cover in the next post!
NEIL PARKHURST 
Leave a comment