Personalized Community is here!
Quickly customize your community to find the content you seek.
Choose your path Increase your proficiency with the Dynamics 365 applications that you already use and learn more about the apps that interest you. Up your game with a learning path tailored to today's Dynamics 365 masterminds and designed to prepare you for industry-recognized Microsoft certifications.
Visit Microsoft Learn
2021 Release Wave 1Discover the latest updates and new features to Dynamics 365 planned April 2021 through September 2021.
Release overview guides and videos Release Plan | Preview 2021 Release Wave 1 Timeline
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
In this post, I will describe “Configurations” in Unified Service Desk (USD) for Dynamics 365 and when you would want to use them. And importantly when not to use them!
A configuration in Unified Service Desk is a set of hosted controls, actions, events etc. Each set of these USD assets is called a configuration. You can then assign a configuration to a user.
Let’s imagine our contact centre is made up of two distinct teams. One team looks after incoming calls from existing customers. This first team would need functionality to manage customer service requests. The second team might make cold calls to leads to try to sell our latest and greatest product. These two groups of users may require significantly different functionality (and agent scripting) within USD. The Configuration option gives us a construct capable of handling this situation.
The first important point to understand is that using configurations in Unified Service Desk is optional, you don’t have to use them! In fact, I would avoid them unless you have a clear requirement to maintain multiple configurations. Why? Well, the upside is I can have differing functionality by user. The downside creating multiple configurations is we’ll increase the ongoing testing and maintenance overhead.
In some scenarios, you may simply want to hide / show a few options to certain users. For example, a supervisor many need access to a few extra buttons or maybe only your administrators should have access to the debug option. In these situations, I would look to use user options or even query the users CRM role. I describe how to achieve this here.
If, however your requirements are more varied / complex then configurations come into play.
Each configuration can be made up of a number of assets, including;
I personally think understanding how something works is often best achieved by looking at a working example! I will therefore create two simple configurations.
User will be given a search toolbar that will show active accounts. Opening an account will start an account session. On an account if I click a contact the contact will open in a tab within the account session.
This will be very similar to configuration one but these users will be given a search toolbar that will show contacts. Opening a contact will start a contact session. And if the account has an associated account, clicking on an account will open that as a tab within the contact session.
I hope you can see that these are two simple configurations but will differ in some significant ways.
Note: I am going to assume you already have an advanced understanding of USD. I am not therefore going describe the detail of how my actions, navigation rules etc operate.
Configuration one will be my default configuration. Each user can be assigned to a configuration but if no configuration is defined they will inherit the default.
As I describe how I created each configuration I will point out a few tips along the way!
My first configuration is shown below. Notice that it is selected as my default. The default option is actually set using the set as default button in the toolbar.
Hosted Controls – notice that I have included all of the hosted controls that are required. This includes some “system” / “essential” ones that must always be present, such as Global Manager, Panel Layout and Connection Manager. What you are seeing here is that each configuration must include all of the required assets not just the ones you have customized.
Events – here I have listed all of the events that have specific actions associated with them. In my very simple example I just included DeskTopReady as in both configurations I decided to load the user CRM home page in a tab when USD opens. (Plus, maximize the screen.)
At this point I would like to mention a challenge! When I use the “+” button to add events I can see a list of the possible events to add but this can be confusing. Even my simple configuration contains multiple CRM Pages, each one will have a set of events with the same name. Every CRM Page, for example, will have an ActiveClosed event. Meaning you could very quickly get confused as to which is which. The screen below shows USD’s out of the box behaviour.
To solve this “irritation” I opened the event entity in customizations and made a change to its lookup view.!
You can see below that I have added the hosted application field to the lookup view. After you have done this make sure you select “Publish all”.
Now when I search for events I can see their associated hosted control. Meaning I could tell which events related to which hosted control. Much simpler to use!
Action Calls, next I listed all of the action calls that applied in my configuration. So, I had actions to search for accounts, navigate to the CRM home page etc.
I continued this theme with my first configuration adding toolbars, windows navigations rules, session lines and options. I didn’t add any entity searches, agent scripts or scriptlets. Simply because my example was simple! But I hope you can see that you could continue to add as many assets as required. Having differing agent scripts maybe something you’d commonly want to achieve with configurations.
Cloning my Configuration
Once I had created and tested my default configuration, I realised that my second configuration would have a lot of commonality to my first. So, cloning the first one and then making changes seemed like a good idea. Luckily Microsoft provide us with a clone option!
So, I opened my Configuration One and used the Clone option from the toolbar.
Having cloned my configuration USD created me a new one called “Configuration One – Copy”. I could now start the process of amending this configuration. (My first task was to rename it from “Configuration One – Copy” to “Configuration Two”.
Altering my Configuration
I can now set about changing my newly created configuration. As mentioned much of my configuration will remain the same and I will share many of the assets in configuration one and configuration two.
In my hosted controls and events sections of the configuration, I made no changes. I could reuse all of this. And in actions I simply removed the old search action I had and inserted a new one. As now I’d want to search by contact instead of account.
Next I remove the main toolbar I did have and created a new one that would include a different search button. One that this time would call my action to search for contacts. I found neither of my window navigation rules were appropriate so I removed both of them and added two new ones.
The final change in my simple solution was to remove the session line I’d created to name the account session and insert a new one to name my contact session.
You may recall the “Configuration One” was defined as my default configuration. Meaning all users would get this unless we state otherwise. You can see in the Users sub-grid at the top of my configuration which users have been assigned this configuration. You can add users to the configuration directly from the configuration form. Or by opening the user’s systemuser record and amending the USD configuration lookup.
Finally, I re-loaded UD and tested my new configuration. I could now search for contacts and had all of the alternative behaviour required.
So, what do I think of configurations???? I admit I have some reservations about the complexity they introduce. For example, I would want to try to re-use assets as much as possible. But in doing so, it would create a need to re-test each configuration separately after a change. BUT, if you need significantly different functionality between users they do offer some significant capabilities.
When using configurations, I would advise all changes to be made via the configurations screens. I actually quite seeing all my assets in one place. The reason I say this is if you navigate to the “standard” USD screens you will see all the assets across all the configurations. Imagine looking at a full list of window navigation rules, many could conflict with each other. So, to avoid confusion, you’ll want to view them in the context of a specific configuration.
In summary configurations, in my opinion should be avoided if possible! But when you do need them they are a big bonus.
Business Applications communities