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 part one I explained what USD is and some of the key concepts and terminology. In part two I covered “install and configure the USD application”. Now let’s start to consider the next section of skills measured statement, “Implement Hosted Controls”. The portion of the skills measured statement that this post hopes to address is shown below;

Implement Hosted Controls

Creating hosted controls

What is a hosted control? You can consider hosted controls to be the objects that make up you USD application. Each hosted control will have a number of UII Actions and Events. Some of the these UII Actions and Events will be specific to a particular type of hosted control. Whilst developers can be create additional custom actions / events.

Creating a hosted control is a simple process. Simply locate the hosted controls option in the settings area.

As an example I have shown a typical hosted control below. In this example I have shown the hosted control I use for my account tab. Each hosted control contains a number of fields such as a name, display name, hosting type etc. I will explain the meaning of many of these below.

Toolbars

When I described hosted controls, you may have spotted that we have a component type of toolbar. We essentially have two types of toolbars available in USD. Ones which are global, such as your main toolbar or about toolbar. And others which are dynamics, showing as navigation toolbars when a tab displays. To illustrate this I have shown some example of these in the screen shot below.

When we have a global toolbar such as the main toolbar, a hosted control will be created with a hosting type of toolbar. Its display group will govern where is displays. (e.g AboutPanel or ToolbarPanel).

Dynamic navigation toolbars are linked to the hosted control(s) they apply to. In my example below that would be the Contact or Cases hosted controls.

The process of creating a toolbar is simple enough. First you create the toolbar and then associate it with one or more hosted controls. (Tip: You access the option to associate the toolbar to hosted controls in the navigation bar of the toolbar.)

Below you can see an example toolbar. In my example I have shown the navigation toolbar from my account tab. Notice that each toolbar then has a number of toolbar buttons.

Each toolbar button contains a number of fields that govern how it displays. And then the actions that will be triggered if / when the button is clicked. As an example I have shown my “email” button below.

Some things to notice about the example above include;

• The “Name” field simply names the toolbar button, it does not display to users.
• Each button can have an image and / or some button text. This defines how the user will see the button.
• Tooltips can be added which will show when the use hovers the mouse over the button.
• The order field dictates the sequence of the buttons on the toolbar.
• Optionally a shortcut key can be added. These allow uses to quickly access functions.
• There is a list of actions that will be performed when the button is clicked. In my simple example, just one action to open the email page is needed. But sometimes many actions may be listed.
• Buttons can be enabled and hidden based on conditions. These conditions will often include replacement parameters. In my example the presence of an email address on the account is needed to show the button.

Events

Events are triggered, sometimes these will be pre-defined events. Such as DeskTopReady which occurs when USD loads. (Found on your Global Manager). Or the events can be custom ones created by developers.

Each hosted control has numerous events. Depending on the hosted control type a different set of pre-defined events will exist.

Each event can be associated with one or more actions. Meaning you can define a list of actions that will be automatically triggered from an event happens. For example, you might want to maximize the screen when USD loads. Or load a particular agent script when a case is opened etc etc.

By way of an example, I have shown my Contact hosted control below. As this is a CRM Page I have a number of standard events. Such as “Saved” which is fired each time something in the CRM Page is saved. Or “BrowserDocumentComplete” which is triggered once the page fully loads.

Below you can see my BrowswerDocumentComplete event from my contact tab. You don’t need to worry what the actions in my example do! But I hope you can see that I can have a number of actions that are automatically triggered when the tab loads. In my example, I decide which agent script to load and then do other “stuff”.

Window Navigation Rules

Window navigation rules govern how tabs (hosted controls) load with Unified Service Desk. For example, when I click on an account in a search window I might want to create a new session. Yet when I click on an account from a contact (already in a session) I might want the account to load within the current session.

Window navigation rules are typically triggered by a user (or configuration) opening somethings. Say loading a contact. But they can also be triggered by “Entity Searches” and “CTi events”.

FYI:

• An entity search means a search which can be created and called using USD configuration.
• CTi, standards for Computer Telephony Integration. Developers can build “listeners” that will trigger events when phone calls are received. We can then build window navigation rules to decide how to react to that event.

I have previously created a blog post in which I attempted to explain the theory behind window navigation rules. You can view this post here.

Whenever required USD will scan all of your window navigation rules in order. When it reaches a rule that matches the current event that rule is triggered and the scanning stops. Each rule will typically trigger a navigation action. Typical actions include “Create Session”, “Show Outside”, “Route Window”, “None” etc. (Tip:
“Route Window” means load the tab into the current session!)

We also have a concept route type. Common route types are “In Place” and “Popup”. Popup meaning that clicking on link is trying to load a new browser tab. Whilst In Place means clicking on a link is trying to load a new tab into the current tab. Because of these two possible route types you may often find window navigation rules are created in pairs!

To help illustrate how window navigation rules operate I have given an example below. In this example, if someone tried to load an account from my search screen a new session will be created. And in that session the target tab will be one called Account. Also notice that I have used the “Hide Navigation Bar” option to control what navigation options will be available to the user.

Tip:
Often you will find the terms “Tab” and “Hosted Control” are interchangeable!

Data Replacement Parameters

Replacement parameters can used when we are customizing USD to insert “variables”. Often these will be fields relating to Dynamics 365 entities we have loaded. For example to return the name of account we might use [[account.name]], surround the name of the parameter by square brackets indicates it is a replacement parameter. When ever “USD sees” [[account.name]] the accounts name will be substituted in place of the replacement parameter.

There are far too many uses of data replacement parameters for me to list them all! I have shown just one example below. In my example I am using the replacement parameters in an expression. This is used as a condition. Essentially I have an agent script to prompt the user to enter any missing contact details, this will be enabled if the contacts phone number or email address fields are blank.

Replacement parameters are more that just fields from the CRM entities loaded! We have some special types of replacement parameters that warrant mention.

Tip:
One good way to help you see and understand replacement parameters is to view them in the debugger!

A few of the “special” classes of replacement parameters are described below;

You can find additional information about replacement parameters here.

When we view replacement parameters for the data with the entities being loaded in USD, often it looks like the collection of parameters is repeated three times! Below you can see that I have a tab called Contact and in that I have loaded an entity called contact. The debugger shows me three sets of replacement parameters!

Often these three will contain the same values. But not always! So understanding the differences might occasionally be important. “contact”, this relates to the last instance of a contact entity that was loaded. “Contact” (Notice the capital C!), this is actually the name of the hosted control that contains my contact entity. (Technically the hosted control could contain anything! I just happen to have called it Contact!) The third variation is a combination of the two concepts just mentioned. So Contact#contact is actually the tab name followed by the entity name. In my example “[[contact.fullname]]”, “[[Contact.fullname]]” and “[[Contact#contact.fullname]]” would all return the same value. But technically each has a slightly different meaning!

I have already mentioned that you can add a “g” to replacement parameters to indicate it is a global variable. There are a few other additions that can be useful. The table below shows a few ….