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.
|General||Name||The unique name of your hosted control|
|Display Name||CRM Pages, standard web pages etc will display! Here we can enter the tab name the users will see. This can be a simple “static name”. Or replacement parameters can be added. For example, we might want to show the account name as the tab name. (I will cover replacement parameters later!)|
|Sort Order||The sort order value specifies the order in which the hosted applications are retrieved and displayed in the agent application. (To be honest I almost always leave this blank!)|
|Unified Service Desk||Unified Service Desk Component Type||Each hosted control has a type. For example, tabs that will contain a Dynamics 365 form will have a type of “CRM Page”. The type selected will govern how the hosted control behaves and what default UII Actions and Events will exist.
Some hosted controls are mandatory. Such as connection manager and global manager. (Covered in my previous post.)
As part of your revision you should probably become familiar with the type hosted control types. You can find details here.
|Allow Multiple Pages||Some hosted controls can support having multiple pages in one tab. You can enable this feature with this option.|
|Hosting Type||When we display a CRM Page (or anything) in a tab one of two browser controls can be used to render the page.
The two supported hosting types are Internal WPF and IE Process.
IE Process is generally speaking the recommended option. It uses Internet Explorer to display the required pages. Because the IE Process hosting type makes use of IE it provides an efficient way to render pages. Giving performance and memory utilisation advantages.
Internal WPF uses the Windows Presentation Foundation (WPF) to use an internal browser control to render pages. This might be useful if (for some reason) you cannot control you Internet Explorer options!
|Pre-Fetch Data||Pre-Fetch is a new option, added at USD v3.0. (Therefore you may not have this option.)
With CRM Pages enabling pre-fetch will load the replacement parameters before the page is completely loaded. (This can give performance advantages!)
|Common Properties||Application is Global||The application is global option is checked for global tabs. And unchecked for any tabs which will show within a session.|
|Display Group||The display group governs the location of the tab. Possible options include;
|Adapter Configuration||Adapter||Typically an advanced feature of custom hosted controls. An adapter can be used when connecting to custom hosted controls.
A User Interface Integration (UII) adapter allows you to modify the behavior of the application without access to its source code. UII provides adapters for web applications, external (Windows-based) applications, and the Hosted Application Toolkit (HAT), which can be extended to build additional application adapter capabilities.
There are three types of application adapters:
|Dynamic||Application is Dynamic||You will find that most of your hosted controls will be dynamic! Essentially meaning that they are loaded / closed dynamically by your configurations / code. (e.g. I only need to load my Account tab when someone opens an account.)
FYI: Dynamics hosted controls that are part of a session would be automatically terminated when the session is closed.
Some controls will not be dynamic, meaning they are loaded as USD opens and are kept open.
|User Can Close||Each dynamic tab that opens has an “x” option that allows the user to close the tab. It is possible to decide if this option is available to users or not.|
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 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”.
- 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.
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.
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;
|$Context||$Context lists a number of variables that will be available for the currently active session. Often you will find replacement parameters that relate to the entity used to start the session. Additionally customizers can use a CopyToContext action to populate values at runtime.
One example of a $Context replacement parameter is [[$Contact.InitialEntity]], this will typically hold the name of the entity that was opened to trigger the session starting.
|$Global||$Global relates to Options in Unified Service Desk. These are constants that are globally available. Some of which drive out of the box functionality in USD, others can be created and used by customizers.
For example [[$Global.maxNumberOfSessions]] is used to reflect the maximum number of sessions an agent is allowed to open.
|$Return||Often an action might return a result. You will find these results in $Return. The parameter name is normally automatically set to the name of the action that generated the result.
[[$Return.<<name of action>>]]
|$Scriptlet||Scriptlets are code “snippets” that can be defined in USD. These can return values.
|$Session||The $Session option is used to return details relating to sessions. One useful parameter here is the count of sessions currently opened. [[$Session.Count]g]
Notice the addition of “g”, this can be used to denote that a replacement parameter is global!
|$Settings||$Settings relates to user options that we can define in the USD configuration. Or set at runtime using a SaveSettings action. These differ from global parameters in that they are user specific.|
|$User||The details relating to the system user record of the current agent.
For example, [[$User.firstname]g]
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 ….
|+||Replaces a null with an empty string. I often include this into my replacement parameters as it provides a consistent approach to handling nulls.
|$||Escapes quotes and line breaks. Useful when working with multi-line strings.|
|^||Flattens a multi-line string.|
|u||URL Encode. Useful when working with urls. (Does things like inserting %20 in place of spaces.)|
|x||XML encode. Escapes characters like <, found in XML code.|
|g||Returns global values.|
|v||Used when you want to replace keys within a replacement key.
Say you have a replacement parameter [[myname]] with a value of “My name is [[contact.fullname]+]”. Normally [[myname]] would return “My name is [[contact.fullname]+]” but using [[myname]v] would return “My name is Neil Parkhurst” etc.