With the release of version 3.3 of Unified Service Desk we now have support for the Unified Client Interface (UCI). I have started to experiment with this! In this post I will try to give you an overview of some of the key points I have found which you might want to be aware of.

Firstly I would like to point out that currently (at USD v3.3) ….. UCI for Unified Service Desk is a preview feature. What does this mean???? Well, Microsoft are simply saying that the feature is pretty new and likely to change. It is therefore possible you may find the odd issue. Additionally preview features could be enhanced or even potentially removed from future versions. Meaning their use is not recommended for production implementations. But generally you can use them for demonstrations and proof of concept work. I have known some companies to use preview features in production environments but doing so would be completely at your own risk.

I have no magic insight into Microsoft’s plans. But I’m reasonably confident that we’ll see a production version of the Unified Client Interface in a USD. As UCI is the intended new standard interface for all of Dynamics 365, hence why I would expect to see full support in USD in due course. (Disclaimer …. this is just my personal opinion and in no way a formal Microsoft policy!)

There has a Microsoft sample package for the Unified Client Interface that you might want to try. It will give you a good idea of what UCI might look like and also it might be useful to review how certain things work! Just run the packagedeployer and select the UCI sample application when installing USD.

Apps

The Unified Client Interface is dependent on Apps. Users must always first open an applicable UCI app. With previous versions of USD we had no concept of an app. Meaning the first new feature for me to describe is the addition of a app picker to Unified Service Desk.

The new App picker is not enabled by default. To enable it you’ll need to alter your UnifiedServiceDesk.exe XML Configuration file. This can be found in the programs directory of your Unified Service Desk client. Below you can see my programs files directory and the UnifiedServiceDesk.exe file within it.

You will need to edit this file, that can be done simply with notepad. (other editors are available!) Scroll down the file until you find the “” section. Then you’ll need to add the line of code shown in red below. This will enable the app selector.

  <appSettings>
    <add key="LoadSessions" value="false"/>
    <add key="enableJava" value="false"/>
    <add key="SupportUri" value="http://go.microsoft.com/fwlink/?LinkID=330917"/>
    <add key="emailSupportUri" value="N/A"/>
    <add key="MaxCrmConnectionTimeOutMinutes" value="20"/>   
    <add key="SelectAppModule" value="true"/>   
  </appSettings>

Now you have enabled the app selector, when you enter credentials into USD an additional screen will be displayed., Having picked your organisation you will be able to pick an app. Obviously if you are using UCI you’ll need to pick an appropriate Unified Interface app!

Once you load a USD configuration (that works with the Unified Client Interface) you’ll end up with an interface that looks something like the one shown below. Notice the tabs have been given a slightly different style and also that the look of agent scripts has been refreshed. The screen shot below is from my USD configuration but you’ll find that the Microsoft sample package has a similar look and feel.

Hosted Control Type

The introduction of the Unified Client Interface means we have a new hosted control type. Below you can see the hosted control I use for my account tab. Notice that the component type is “Unified Interface Page”. (When previously it would have been CRM Page.)

Tip:
I have found that you can’t just alter the component type on an existing CRM Page hosted control! You’ll need to create a new hosted control for any tabs you’d like to display as the Unified Client Interface. I guess the reason being that a Unified Interface Page hosted control has a few different actions / events. (More on those in a second!)

Events

Below you can see the events I have by default on a Unified Interface Page hosted control. These differ slightly to the events you might be familiar with from the CRM Page hosted controls.

I am still experimenting with Unified Interface Page hosted controls! (But I will document the differences I have observed so far below.)

PageReady

Importantly we no longer have the commonly used BrowserDocumentComplete event! It has been replaced by PageReady.

PageReady behaves in the same way as BrowserDocumentComplete, in that it is triggered once the form has loaded.

DataReady

Not forgetting that we also have a DataReady event, this event is triggered as soon as the replacement parameters are available when a form is loaded. We did have this event with the CRM Page hosted controls but had to be added manually. I believe it gets created by default with Unified Interface Page hosted controls.

NavigationRequested

I believe NavigationRequested is triggered each time we try to “pop” a record in a tab. I hesitated to use the word pop! As you might need to understand that the Unified Client Interface only generates In Place routes, no pop up occurs. (I will mention this again when reviewing window navigation rules!)

Uii Actions

By default the Unified Interface Page does not have the following actions, which would be present on CRM Page hosted controls;

• DisableToolbarButton
• EnableToolbarButton
• LoadArea
• lookupinfo
• ReRoute
• ToggleNavigation
• ToggleRibbon
• WaitForComplete
• WaitForData

I haven’t yet tested to see if any of there uii actions can be added manually!

The following actions are added;

• New – As far as I can tell so far, the New action seems to be the same as the New_CRM_Page action. (In that it loads new pages.)
• Open – Open is the same as Open_CRM_Page, as it opens existing records.
• SetVisualProperty – I’ve not used this on a Unified Interface Page, yet!

RunXrmCommands

RunXrmCommand actions are different with the Unified Client Interface. I have already documented the differences in this post.

Essentially we can no longer use JavaScript that includes Xrm.Page with the Unified Client Interface. The new approach to RunXrmCommands allows us to specify a webresource and function to run. This approach allows the context to be passed into your JavaScript function. (Therefore removing the need for Xrm.Page commands!)

Window Navigation Rules

Window navigation rules are slightly different with the Unified Client Interface! With the standard web client in CRM Page hosted controls we often have a pop up route. (Popups commonly occur when opening a new record, meaning I often have a window navigation rule which creates a new session when a popup occurs from a search tab etc.)

With UCI we get no popup routes, all routes are “In Place” routes. The implication of this is that you might need to review your approach to window navigation rules. I actually think this could be a benefit as with CRM Page hosted controls we typically created two navigation rules, one for the Popup route and another for the In Place route. Having just one route therefore means we can have less navigation rules.

Enhanced look and feel

Whilst converting my configuration to work with the Unified Client Interface I found it really useful to review how various actions / hosted controls are defined in Microsoft’s sample package. This was very true when understanding the approach needed to implement the enhanced screen layout show in my screen shot at the start of this post.

Assuming you might also want to clone this style, I will provide a few tips below…..

Firstly, the panel layout isn’t the standard one. Notice that the Panel type is XAML. I won’t include a copy of the XAML here. As all I did was copy and paste if from the Microsoft sample package.

Next you will find three actions that need to exist on the DeskTopReady event of your Global Manager. These are;

• Set UCI Custom Theme Normal Contrast
• Set UCI Custom Theme Tabs
• Set UCI Custom Theme Toolbars

I won’t list the details for each of these actions here! Simply as your quickest approach will be to load the sample package and cut and paste the details for each action from there! Each action is a SetTheme action that includes some XAML code to correctly format the tabs / toolbars etc. (Depending on your requirements you may find you need to edit this XAML!!)

Hopefully this post has includes a few useful tips around the new Unified Interface Client support. I am really enoying working with the new interface and I’m looking forward to when I can implement it in a production environment.

Recently I have started to work with the new feature with have in Unified Service Desk 3.3 that supports Microsoft’s Unified Client Interface (UCI). As I find differences or tips I will create short blog posts.

In this post I will cover how the category or relevance search is loaded in UCI. It works in a similar way to the web client but there are some small differences, as you will see below.

The multi-entity searches with the standard web client were achieved using a navigate action to this URL; “/multientityquickfind/multientityquickfind.aspx?sitemappath=Settings%7cSystem_Setting%7cnav_administration&text=“.

This won’t work with UCI, instead we’ll need a navigate action to this URL; “/main.aspx?pagetype=search“.

By way of an example I have shown a search action I use;

The multi-entity search operates the same in the Unified Client Interface as it did in the web client interface, although it looks slightly different.

You can see how the relevance search appeared in my interface;

If you are experimenting with UCI and USD I hope you’ll find this information useful.

Have you ever presented to a room full of people or given a webinar? If so you probably know that it can be an exhilarating experience. But then you probably also know that anything that can go wrong typically will go wrong. Last night that’s what happened to me! By way of an apology here is “take two” of my demo …… it shows how to quickly create a Unified Service Desk application using Microsoft’s new interface standard for Dynamics 365, the Unified Client Interface (UCI).

I gave my presentation as part of the D365UG’s virtual summer camp, the idea was to explain how great USD is and then complete a live demo of building a simple application.

Please checkout https://www.d365ug.com where you should be able to find the original full recording.

After my presentation I repeated the demo. The recording of my second attempt is below…

In Unified Service Desk I often only want to run actions when a particular tab is open. The problem is users are unpredictable things and they may have closed the tab without me knowing or maybe they never opened it. I could just run all the actions regardless and ignore any errors. But I don’t like doing that and it isn’t an efficient way of designing a solution. So, what so we do?

The solution is really simple and one I use on a regular basis, but I don’t think I have mentioned it in my blog before. So here goes ….

Imagine you want to run some JavaScript on the phone call tab but you don’t know if the user has that open. What would the action need to look like to not cause an error?

Imagine I have a RunXrmCommand action like the one below. Whatever code I want to run on my phone call tab will fail if the tab isn’t open.

Stopping the error is easy! Simply add a condition that uses “IsAppLoaded”.

CRMGlobalManager.IsAppLoaded("<<Your tab name>>")===true

Now the action will only run if the phonecall tab is loaded!

Hopefully this is a simple tip but one that is useful to USD fans! Enjoy.

I recently had a requirement to be able to quickly resolve a case in Microsoft’s Unified Service Desk (USD), in the end the solution was really easy but not quite what I expected. Here is my solution ….

You probably know that out of the box the resolve case button displays a dialog that can’t be customised. Often organisations will require a simpler approach. As a reminder standard dialog is shown below;

I wanted a simple agent script to resolve the case without the agents having to complete this dialog. I didn’t really care what went into the resolution text or billable time. I just wanted the case to be resolved but I wanted it done “properly”, meaning I wanted to still see the resolution activity. I happened to recall that the Microsoft standard USD sample package for the web client included an agent script to resolve a case. So, I turned to that to look at how it worked. The answers turned out to be simple but not what I expected. It involves using their “KPI” control!

My final solution was very closely based on the config found in the Microsoft sample web client package. Except I added a few variations which I felt improved the user experience.

The steps involved are shown below;

1. You will need the customizations zip from the sample package.
2. Create a KPI hosted control. (If you haven’t got one.)
3. Check you have correct UII Action
4. Create an action to resolve the case.
5. Create an action to re-display the case.
6. Create an agent script answer to resolve a case.

Step One – You will need the customizations zip from the sample package

The sample package includes a custom hosted control that is included as a customizations.zip file. If your solution happens to be based on Microsoft’s sample package then you may already have this. If it isn’t you will need the zip file from the sample package. How do you get that? It is actually quite easy … once the Microsoft packagedeployer has been extracted you will find a folder called “CRMWebClientDemoPackage”. And in here you will find USD_AgentDesktop.zip. This is the file you need.

In the customizations area of Unified Service Desk settings create a new customization file. The name doesn’t really matter! But attach the USD_AgentDesktop.zip.

Step Two – Create a KPI hosted control

Now you have the customization zip created you can create the required hosted control. Again if your solution is based on Microsoft’s sample web client package you might be able to skip this step.

Mine looks like this ….

As a side note …. This post is about the ability to resolve cases. But the KPI control can obviously also be used to display KPIs! Shocking revelation I know!! (I might cover the details of how this can be amended in a future post.) But below is show the standard Microsoft Extensions XMl which when added will support showing KPIs. (Another topic for another day!!)

Step Three – Check you have correct UII Action

Next in the navigation of your new hosted control, select UII Actions. You need to check you have an UII Action called “ResolveCase”. If that doesn’t exist simply use the “ADD NEW UII ACTION” to cerate one.

Step Four – Create an action to resolve the case

That is the complicated stuff completed! Now we simply need to create an action that will resolve cases.

My action is shown below;

Step Five – Create an action to re-display the case

In my solution, after resolving the case I wanted the screen to refresh. So that the now read-only resolved case was displayed to the user. I found that a simple refresh action worked but the navigation bar then showed. I didn’t like that so I wanted a cleaner approach. Hence, I used a navigate action. My action is shown below;

Step Six – Create an agent script answer to resolve a case

So finally, I decided to pull these actions together in an agent script answer. You could also have do this in a toolbar button! I already had an agent script for cases. So below I will just show you the agent script answer but you might also need to create an agent script for cases, if you haven’t got one.

My agent script answer is below;

My Change Working

When I click on the agent script to resolve case the case gets resolved. Plus, it re-displayed as the read-only resolved case. And my agent script is only enabled if a saved, active case is open.

And the icing on the cake is that a resolution activity is correctly created. Showing that the case was resolved form within USD.

A Word of Warning!

Buyer beware! The Microsoft sample package works great but it is not supported for production use, meaning if you find any issues with this approach Microsoft will probably not support it. Personally, I am prepared to take the risk! If any issues happen I would need to create a custom approach which would do the same thing. I might do that if I hit a problem …. Which I haven’t yet. Enjoy.

All browsers are pretty much the same thing, right??? The actual answer to this question is a resounding no! When working with Microsoft’s Unified Service Desk (USD) selecting the “correct” browser for your hosting type can make the difference between a solution that’s fit for purpose and one that is slow and unreliable.

Or put another way, your browser choice can be the difference between a project failing or succeeding! So, what are our options and what might influence your choice? In this post I’ll explore the various browser options and give my opinions on best practice. All of the information stated is available in the Microsoft documentation, I am simply presenting it in a single post and giving my views on how the options compare. (Links to the associated Microsoft technical information are provided!)

In recent versions of USD Microsoft have expanded the number of browser options available, so what previously had been an easy choice is now more involved. Our options include;

• Internal WPF
  
• IE Process
  
• Edge Process
  
• Chrome Process (Currently in public preview)
  

Whatever browser you opt for, one tip I have is to select your intended browser at the start of your project. Then complete all development and testing using it, taking care to ensure your development environments mirror the configuration of production. That way you will help uncover and resolve any issues prior to live deployment. Also, if you do change from one browser to another be aware that a level of regression testing will be required!

I say this as browser choice can give slightly different results in terms of how your configuration behaves, pages are rendered and importantly how your solution performs. Completing all testing using your intended configuration should help reduce the risk of any shocks post deployment.

Let’s begin with ruling one option out! I do not recommend using Internal WPF. I would go as far as to encourage Microsoft to deprecate Internal WPF ….

In the early days of USD maybe WPF was a realistic option. Very occasionally I’ve seen a reason to use USD’s internal browser when other options like IE aren’t available. But now we have multiple browser options, meaning resorting to Internal WPF should never happen. I feel the WPF option to be slow, wasteful of memory and may not render pages as expected. In my opinion it should be avoided. (Although I would be interested in hearing about any use cases that suggest a valid reason to implement Internal WPF.)

Warning: This post includes my preferences. You may have different experiences to me, the views expressed here are just my opinions. Microsoft’s official guidance could differ from the personal opinions I express here!

IE Process

Until recently IE would have been my only recommended browser choice. I have found it to be significantly more reliable and faster than Internal WPF.

IE Process handles memory better than WPF and the usdmp.exe
process uses the ProcessTerminationThreshold option to monitor processes. Keeping USD responsive if a single browser “tab” fails.

In some circumstances IE may still be the preferred option.

Getting your IE options correct has been a historic challenge. For example, protected mode needs to be enabled in all security zones. Failing to do this can result in USD behaving in some unexpected ways. (Such as sessions not opening correctly.) A common support issue has been that some (or all) of the agents report unexpected behaviours resulting from IE options. Although these days we do have the best practice analyser which will check our config and suggest revisions to IE options. If you haven’t used the best practice analyser I strongly recommend you look into it. (Regardless of your browser choice.)

The introduction of the InternerExplorerPooling
option did give IE a performance gain. Although I have observed some reliability challenges. I do recommend enabling the IE Pooling option. But if you experience any strange behaviours, including ribbon bar buttons not displaying as expected try disabling it! To be honest I have routinely enabled IE pooling for demonstrations but in production scenarios I have reluctantly needed to disable it.

We can not ignore the fact that IE is an aging browser, it has been around for many years and whilst very robust some newer web-based applications are now unsupported. Generally speaking this hasn’t presented me with any production issues but as time marches on I expect the age of IE to become an issue.

You can find additional information about IE Process here … https://docs.microsoft.com/en-us/dynamics365/customer-engagement/unified-service-desk/ie-process?view=dynamics-usd-4.1

Edge Process

Edge certainly ticks the box of being a newer browser than IE and does have some potential performance benefits.

I have attempted to create some statistics giving a meaningful comparison between each browser option. But any timings are very subjective as many other external factors influence the results. But I can say Edge does “feel” faster than IE. But (in my experience / opinion) by a relatively small margin. I have already commented this post is my opinions, your experiences could differ from mine!

Edge is only supported on Windows 10 versions later than October 2018. In my test environments this doesn’t represent an issue and I have been happily using Edge for some time. But production use may present different challenges … I’ve seen thin clients commonly deployed in contact centres that would be based on Windows Server operating systems or often the hardware (and therefore operating system software) can be “mixed”. It maybe quite common for some agents to be working with aging kit. In these scenarios using the latest windows 10 desktop operating system may present challenges. Obviously, this is a challenge that can be addressed by upgrading your infrastructure but that might be costly!

The elephant in the room with Edge is that Microsoft has announced an intention to redevelop it to work on Chromium. (You can see the announcement published by Joe Belfiore, Corporate Vice President of Windows below.) Obviously, I don’t know the future implications for Edge with Unified Service Desk …. but I do know that fully testing a contact center application can be a significant task. Meaning if you do implement Edge be aware of the potential for future rework. Additionally this would suggest using the “Chrome Process” may be more future proofed. (Again just my opinion!)

Edge (and Chrome) include a limitation that neither support multiple tabs. (At least not currently.) If you absolutely require the multiple tabs feature, then IE will currently remain your browser of choice. I’ve found multiple tabs useful when agents what to do things like repeatedly review old cases or closed activities. I use them to load a form once and allow agents to quickly swap back to the record without needing to reload the form. With IE this might be considered a big benefit but Edge (and Chrome) render the pages faster in the first place, so in my scenarios ditching multiple tabs in preference for general performance gains has been a no brainer.

You can find out more about using the Edge browser here … https://docs.microsoft.com/en-us/dynamics365/customer-engagement/unified-service-desk/edge-process?view=dynamics-usd-4.1

Chrome Process

Chrome is available in USD 4.1. Currently it is available for public preview as part of the insider program but should be available more generally “soon”. (as of March 2019.) Obviously, Chrome maybe on general availability by the time you are reading this post! But even if isn’t, I’m already aware of some people implementing Chrome for production purposes.

For me, the key advantage of Chrome is that it will work with any operating system. I have also found no issues to worry about in terms of Chrome settings. Additionally, Chrome is noticeably faster than IE or Edge.

Its possibly a little early to fully comment on Chrome’s reliability (Chrome support being relatively new!) …. but so far I haven’t experienced any significant issues. And I’m happy to use it.

You may however need to make some tweaks to your USD configuration! Chrome runs scripts asynchronously, I guess this is one reason its fast! But it does mean any RunScript actions may need to be reviewed. If you have a RunScript action that immediately uses the result then you may need to add an ExecuteOnDataAvailable action to delay processing. My configuration contained multiple RunScript actions but even so the required changes only took me a couple of hours. A small price to pay for the level of performance benefit.

Like IE, there is an option to implement chrome browser pooling. This may be enabled by default and does result in a noticeable performance gain. But I have experienced a few related reliability concerns. I believe Microsoft are working on any issues, therefore I recommend you ensure your using the latest version of USD! I suggest initially testing with pooling enabled but if you hit any issues disable this feature and try again! (My issues included challenges with the display of toolbars and refreshing of Dynamics 365 forms.)

Tip:
Having suggested you should consider disabling ChromiumBrowserPooling, each time there is a new version of USD I also suggest re-testing. As I expect any reported issues will eventually be resolved. And you do want to enable pooling as the performance benefits are significant!

Chrome zoom level may also need to be set. I personally found the default zoom level “not ideal”! For me adding a zoom of 0.4 resolved the issue. I haven’t tried this in a production setup, yet! One query I have is that the zoom level will be common to all users. Whilst some contact centers will have a consistent set of hardware this is very often far from the truth. In an environment with mixed screen sizes / resolutions we may need to experiment to see how well this zoom option works. I haven’t actually experienced any issues but you may want to ensure any testing includes all of the resolution options you need to support. (Just to be safe!)

So Chrome is new and as we’d should expect has some limitations. I know this might be sounding a little bad for Chrome! But the performance gains are so significant I am more than prepared to recommend Chrome. It is now my go to USD browser.

You can find out more about using Chrome process here … https://docs.microsoft.com/en-us/dynamics365/customer-engagement/unified-service-desk/chrome-process?view=dynamics-usd-4.1

Conclusion

I did say this post was my opinion … your experiences may differ from mine! If they do I would like to hear about them.

In my opinion ….. my first choice of browser (from now onwards) will be Chrome. And if anything prevents that I will revert back to IE. I will not be using Edge or Internal WPF.

I have nothing against Edge and agree it is a useful option. But I simply favour Chrome. This is largely because of the longer-term roadmap for Edge and its move to become Chromium based. Plus, Edge only working on specific Windows versions is a deal breaker for some contact centers.

So that’s it then (in my opinion, the answer is simple) … if in your contact center you want the most reliable / established USD browser, use IE Process. (For now.)

But If (like me) you want the fastest possible experience and to have an eye on the future then use Chrome. For me, Chrome is the “winner”.

As I have said, several times, this is just my opinion ….. if your opinion differs I’d be interested to hear your experiences.

I love it when I find something new in Unified Service Desk! I recently spotted an action I’d not used before whilst experimenting with USD v4.1. SetReplacementParameter. But what does this action do and why would you want to use it?

Often in my USD configuration I find the need to store variables as replacement parameters. Commonly the values are specific to my current active session, in this situation we use the “CopyToContext” action. I wrote about CopyToContext back in 2016! You can read that post here.

CopyToContext is great but what if you want to store a value that is global to all sessions? This is when we can use the SetReplacementParameter action.

Your first step might be to create the required UII action.

Note:
I am using USD v4.1 public preview version. I haven’t done any tests to see if this action works with earlier versions!

Create UII Action

Before you can experiment with SetReplacementParameter you may need to add it as a UII action on your Global Manager hosted control. To do this open your Global Manager and use the “Related” option to navigate to “UII Actions”.

Within UII Actions, if you don’t have an action called SetReplacementParameter. Simply use the “Add New UII Action” option and create it.

How Does SetReplacementParameter Work?

If you attempt to create an action call using the SetReplacementParameter UII action you’ll see the following help. It tells you pretty much everything you need to know!

Below you can see that in the USD debugger I have added a global replacement parameter to an existing global application. (Called Announcements.)

Tip: Don’t forget to refresh your Data Parameters after running an action like this!

In this example, I can now use the parameter [[Announcements.MYTESTPARAM]g] to return my newly created global variable.

In this next example I decided to enter an appname that didn’t already exist. Here you can see that it created a new app key field value. [[$Global_Values.MYTESTPARAM]g]

I can imagine this to be really useful if I want to store a list of dynamic global value.

Hopefully you can see that this action could be really useful to anyone configuring Unified Service Desk. Enjoy.

I am currently VERY hard at work preparing training material for three courses I’ll be delivering in Australia in August. During my preparation I realised that the logic for displaying associated views in Unified Service Desk was different between the Classic web interface of Dynamics 365 and the newer Unified Interface. In this post I will document how to display an associated view using USD and the Unified Interface. (As I noticed several forum posts with people asking how to achieve this.)

But first …. If you are a USD fan and based in Australia you mighty be in luck! As we still have a few spaces available, checkout this links below;

• Brisbane

  https://www.eventbrite.com.au/e/usd-omnichannel-masterclass-brisbane-tickets-63038123725
  

• Melbourne

  https://www.eventbrite.com.au/e/usd-omnichannel-masterclass-melbourne-tickets-63554714863
  

• Sydney

  https://www.eventbrite.com.au/e/usd-omnichannel-masterclass-sydney-tickets-64302367111
  

The steps involved in displaying an associated view using the Unified Interface are these;

1. Create a hosted control.
2. Create an action.
3. Trigger the action, say when you load an account.

Step One – Create a hosted control

You’ll need a hosted control to display the associated view in.

Step Two – Create an action

Next you will need an action to display your associated view.

So what if you aren’t sure of the navItemId? I quickly wrote some code which would loop round my navigation items. As a test I added this to the OnLoad event of my account form. I noted the values I needed and then removed the code again. There might be quicker ways to find this information but this approach worked well and was pretty easy. The code I uses is shown below;

function OnLoad() {
  var navs = Xrm.Page.ui.navigation.items.get();
  for (var i in navs) {
    var nav = navs[i];
    alert("Name:" + nav.getLabel() + "   ID:" +nav.getId());
  }
}

Step Three – Trigger the action

There are probably loads of ways to trigger this action! Maybe you could have a toolbar button that when clicked would open the associated view.

In my simple example I just added the action to the PageReady event of my account hosted control. As that is triggered each time the account form finishes loading. Simples!

My Test

Below you can see that the associated view is displayed in the left panel of my USD solution. What I really like about the Unified Interface in USD is that the small space available in the LeftPanelFill (or RightPanel) triggers the mobile version of the form to render. I think it makes for a great user experience.

Displaying associated views is a simple task easily completed!

It is just one of the many things you could learn during my training course in Australia. Come can join us, you won’t regret it …

• Brisbane

  https://www.eventbrite.com.au/e/usd-omnichannel-masterclass-brisbane-tickets-63038123725
  

• Melbourne

  https://www.eventbrite.com.au/e/usd-omnichannel-masterclass-melbourne-tickets-63554714863
  

• Sydney

  https://www.eventbrite.com.au/e/usd-omnichannel-masterclass-sydney-tickets-64302367111
  

I love it when I’m asked fantastic questions! Recently someone reported a problem whilst using the window.IsUSD command. If you don’t know this is a JavaScript command we can use to see if our code is being run within USD or not.

The problem was that the window.IsUSD command seemed to no longer work. Probably because they were now using the new Unified Interface rather than the web client or possibly because Chrome Proecss was now being used for the hosting type. One possible (partial) solution is to alter your JavaScript to use “parent.window.IsUSD”. Certainly in some circumstances this appears to resolve the issue.

However even this could still result in an occasional reliability issue! If you are using chrome process as the hosting type then you may still see the IsUSD command fail occasionally. Microsoft explain here. My limited understanding is that the potential “reliability” issues with window.IsUSD relates to the asynchronous nature of chrome process. Meaning, your JavaScript code using a window.IsUSD command could be triggered before the IsUSD value has been set to true. Meaning the code could be unpredictable. One solution is to ensure all of your code is triggered only from predefined USD events such as PageReady. That is fine but you may prefer to add code directly to your Dynamics 365 form. In this post I will describe an alternative approach which you might want to consider.

This alternative approach relies in using a RunScript action when the hosted control is first loaded. By running localStorage.setItem(“isUSD”, “true”) I can then use commands like localStorage.getItem(‘isUSD’) to confirm if the code is being run within Unified Service Desk or not.

I originally blogged about the window.IsUSD feature here. I also showed one possible use for this feature in triggering the load of an account’s website in this post.

Whenever I describe a feature I like to offer an example solution, as in my opinion that helps to give context. Therefore I returned to my earlier example of wanting to load the account’s website from the on-change event on the account form. I decided to update this example, to work with this alternative approach. (And as a result support both the Unified Interface and Chrome Process.)

The steps involved are;

1. Create a hosted control
2. Create JavaScript on OnChange of Website
3. Create a RunScript Action
4. Create an action to load the account website
5. Create an event

Tip: This steps might sound complicated but this is a pretty simple example!

Step One – Create a Hosted Control

My first step was to create a hosted control to hold my accounts website. As when a user changes the website field on my account form I want a tab to open containing the newly entered website.

Step Two – Create JavaScript on OnChange of Website

I am going to assume here that you know how to add JavaScript into Dynamics 365 forms!

Essentially what I required was some code that would trigger a USD event each time the website changed. But I didn’t want this code to be triggered if the same onchange event was triggered from outside of USD. You can see below that I have added a form library and in that I have created a function which will be triggered on change of the website field on my account form.

Additionally I have used the edit button and ensured that the “pass execution context as first parameter” option is selected.

The code I added looked like this;

function onChange_Website (executionContext) {
  var context = executionContext.getFormContext(); 
  // *** Ensure website is a fully qualified address
  var website = context.getAttribute("websiteurl").getValue();
  if(website.substring(0, 4) != "http") {
    website = "http://" + website
  }
  var isUSD = localStorage.getItem('isUSD');
  // *** If I am in USD then fire a USD event!
  if(isUSD == "true") {
    window.open("http://event/?eventname=AccountWebsiteOnChange&WEBSITE=" + website);
  }

Notice that I have highlighted in red the command(s) used to check if this code is being run within USD. We will look how to set the “isUSD” value in a second!

Step Three – Create a RunScript Action

Next I want a RunScipt action call that will set my isUSD value.

This RunScript action needs to be triggered when my Account hosted control is loaded. So I simply added it to the PageReady event on Account. The end result being that each time my Account hosted control loads a value of “isUSD” will be set to true.

Step Four – Create an action to load the account website

I wanted an action to actually load my account website. That was simply a navigate action.

Step Five – Create an event

Next I wanted to create an event on my Account hosted control, this will be triggered each time the website on the account form changes. I will simply add my navigate action into that event.

Below you can see that I have used the “Related” option to open the “Events” tab. Within the events tab I have simply used the “New Event” button to create an event called “AccountWebsiteOnChange”. This event will be triggered by the JavaScript that will run on my account form.

Once I’d created my event I opened it and added the navigate action we created in step four.

Hopefully within this simple example you can see that I can use a RunScript command including “localStorage.setItem(“isUSD”, “true”)” to set “isUSD” to a true value. Then in any JavaScript I can use “localStorage.getItem(‘isUSD’)” to reference that value. And therefore know if the code is being run within Unified Service Desk or not. Enjoy.