Microsoft Unified Service Desk (USD) Configuration 101 - Usage and Entities

With a new year right around the corner, I figured I could talk about one of the fairly new areas/products of Microsoft CRM: the Unified Service Desk (USD).  I've had the chance to work with early versions of this product and have been involved in a deployment to a call center, so I have first-hand knowledge and a production deployment under my belt with this offering from Microsoft. Hopefully I can pass some of that knowledge onto others.

From what I've seen online, there's a lot of documentation and articles out there about what USD is and at length about how to use pieces of it, but most of it isn't very user friendly or easy to read.  I'm hoping to change that here.  I won't go into gruesome details about CCA, CCD, UII, and all the technical components in this post; hence the 101 designation in the post title.  I believe that seeing USD in action is the best way to understand how it works, so if you can, I recommend getting a demo site of CRM set up, installing USD, and going back and forth between your installation and this post as you read about the different components.  Of course, you can just read this start to finish and you'll get a lot out of it (I hope), but you'll get more if you get your hands dirty.  Just to give a quick figure, there are literally hundreds of records that are created from this demo data being installed.  You can even use it as a base to install your actual USD implementation.

Before I get into explaining how USD is installed and configured, a quick word on what USD actually is.  USD is a client-hosted application that captures, groups, and displays the web-based Microsoft Dynamics CRM forms.  At the end of the day you're still connecting to your CRM website, but you're doing it through a desktop executable.  Why would you do this?  USD provides many benefits that the website cannot do on its own, listed below:

• It is easily integrated with Microsoft Dynamics CRM out of the box.  No coding is required to have the desktop application display and interact with CRM.  This makes it a perfect starting point as opposed to making something on your own to integrate with CRM.
• It can keep track of many sessions at the same time, so users can do work for many different clients at once and their data will stay separated on the screen.
• It integrates and hosts other applications easily.
• It provides an easy way to automate processes in both CRM and other systems, as well as transfer information between those systems.

USD does not need to be pigeon-holed into a call center only product, although it does lend itself very well to that use case.  If a CRM implementation also has to interact with many other systems at the same time (ERP, websites, phone software), USD is a great candidate to connect all those applications.  Even if your users are using multiple systems that aren't related to CRM it can be a benefit, as that's where automation comes into play.  For example, say you own a car repair shop.  A caller calls in and says they're still having an issue with their steering alignment.  With one button click in USD, the application can:

• Bring up customer information
• Show recent cases in CRM
• Open a new case for the client
• Display their open balance in an ERP system
• Display the manual for that client's car to help a technician fix the problem.

Yes, unlike CRM and most products from the last 5 years, USD is not web-based.  The configuration records are on the web in CRM, but the interpretation of those records is done on the client.  If you don't have any custom integrations, all deployments/updates are done on the server.  If you do have custom components, they're compiled into DLLs and placed in the USD folder.

USD Installation

Installing USD is fairly simple if you follow the installation instructions provided by Microsoft.  I highly recommend installing the demo data that it comes with as it gives you a ton of records to play with.  The installation is in two parts, one for the server and one for the client.  And honestly, using the term 'installation' for both of these pieces is being pretty generous.  The server installation is just a solution install and data import.  The client installation is just copying a bunch of files to a folder of your choosing.  There aren't any files actually 'installed' anywhere else as we know it in terms of most Windows applications.

Configuring USD

Configuring USD is done through creating records within CRM.  When USD loads on a user's machine, after logging in the server will be contacted to retrieve records from the USD entities.  This configuration is made up of 15-20 different entities, many of them obvious but some of them a little more convoluted and harder to understand.  Here I'll go through some of the more basic ones.  Since a call center is touted as the main use of USD, I'll use that as a running theme.

First, what I consider the main four entities:

• Hosted Controls - The Objects of USD.  If you know Object Oriented Programming, these are the objects.  Most of the 'things' you make in CCD are hosted controls.  This includes your tabs, the debugger, any phone integration visuals, custom components, and even the global manager of USD.  When you have a new USD installation, you need to at least have a Global Manager setup.  Again, though, that's beyond the surface of USD so I'll leave the details of that for another post.
• Events - Simply, things that happen.  This can be a web page finishing loading, a user clicking a button, or a phone call coming in and being picked up by USD.
• UII Actions - Reactions to events.  For example, if someone clicks on a button, what happens?  Does a form open?  Is data saved somewhere?  Does a page close?  All of that is handled through actions.
• Actions - These are the links between Events and UII actions.  You have an Event of clicking a button and a UII Action of saving a record, the Action record would link those two things up so that when the button is clicked, the record is saved.  This way you can use the same action multiple times, maybe you want the record saved automatically if someone closes a form, a button is pressed, or agent scripting is used (more on agent scripting later).

So you have the items, what they do, and how they respond.  You can have multiple actions fire off of one event happening, such as saving a record and then closing a tab.  You can even have actions fire off of other actions.  So if you want to retrieve information and then use that information after it's retrieved, you can set that up.  If you fired both events in parallel there's a chance the data won't be available and the call would fail.

Tying this to the call center example, your hosted control would be a CRM form, say, a Contact entity.  Your Event could be clicking on an activities button to bring up activities related to that contact, the Action would be to show a grid of activities, which would call the UII Action to do the actual display.  Note that the Activities button I mentioned is a USD button, not the one within CRM.  This is  done through toolbars, explained below.

Visual Components:

• Toolbars - These should look familiar, they're like any toolbar in windows applications.  They're used to hold toolbar buttons which are used to fire events.
• Toolbar Buttons - As mentioned above, these are used to fire events in USD.  Some common uses are to open Advanced Find in CRM, link to external websites, or open the debugger.
• Agent Scripting - Helps guide users though the use of USD and CRM.  It gives a script for users to say to users if they're communicating with someone, and they can also help drive business logic through options.  For example, if someone is calling in to order a product vs. asking for support, you would have totally different things happen in terms of what records are created or screens are shown.
• Session Lines - A 'mini area' of USD, usually used to show often-used information about a customer in the current session (more on sessions later).  If you're in a financial implementation, you can place company name, market cap, stock ticker here.  If you're selling homes, you can place the price of the home and number of bedrooms/bathrooms that a client is interested in.

To keep with the theme of a healthcare call center, in the top left of your USD screen would be a client's name, coverage plan, maybe their deductibles.  That's the session line for this client.  Above your phone call form would be a toolbar and on that toolbar you can have multiple toolbar buttons:  Save, close, create email, open a URL to an external website...anything you'd like.  If on this phone call the user is to determine why the user is calling (maybe they're asking about eligibility, maybe they're asking about changing their primary care physician), you would use Agent Scripting.  The script could contain language telling the user to ask why the caller is calling and then give options.  If a user clicks on one of those options, say the caller is calling about an existing issue, USD can open up a grid showing all service requests that are related to that customer, and possibly open a help website or if there is only one open service request, open that record.

I'll pause here as that should be enough to digest for one post.  I mentioned this at the start but it's that important:  Install the data that comes with the USD download and use it.  Explore it.  Play with it.  Everyone that I've worked with that knows this product, myself included, has learned and gotten used to the product from using it and not just reading about it.

Next time I'll go through more of the entities and components of USD:  Options, Window Navigation rules, Scriptlets, the debuggger, what Replacement Parameters are, and some of the smaller entities involved in configuring USD.  I'll also have future posts on making a custom hosted control and integrating with other applications.

As I'm sure you can tell, this is just scratching the surface of USD. If you have any specific questions or topics you'd like me to go over, feel free to send me an email!