Tag Archives: unified service desk

USD: Remove individual hosted control parameters from memory

In our Unified Service Desk implementation (by the way, we’re live and everyone’s happy–YAY!), we are using a particular technique for showing the same entity type on multiple tabs. The nitty-gritty on how to do that is in this article I wrote a while ago.

The TL;DR on this is that we create more than one hosted control for a particular entity. When the entity record is requested, there’s a set of navigation rules that start looking at the URL parameter of the hosted controls, one by one. So if the first hosted control URL is empty, it loads that one, opening a new tab. Let’s say you call another record of the same entity type. It goes again through the navigation rules, checks the URL of the first hosted control, finds that it’s not blank or null, and then the next rule is fired, checking the URL for the second hosted control. If it finds it empty, then it loads that control in a new tab.

So much for a brief description.

When you close a tab, the hosted control parameters are kept in memory. One of the issues we found is that once you used a hosted control, if you close it, the control cannot be reused because the code looks for an empty or non-existing URL parameter to load up the different hosted controls. This would cause us to sometimes hit our control limit for that particular entity.

So we needed to clear the URL parameter. How?

The solution implemented is based on our USD custom panel, so it’s not handled via configuration. However, let me add before explaining that there’s a way to clear all parameters from a hosted control. You can do this by using the ClearDataParameter action, passing the parameter “name=topLevelTreeName“, where topLevelTreeName would be the hosted control or entity you want to clear. As it implies, it’ll clear all parameters for that entity; something you might want to do.

In our case, however, we only wanted to clear the URL parameter, and this is how we did it:

First, we set an event handler for the RequestApplicationClose event on the AppHost object:

 protected override void SessionCreatedEvent(Session session)
     session.AppHost.RequestApplicationClose += AppHost_RequestApplicationClose;

This event handler is wired up when a new session is created by overriding the SessionCreatedEvent method, since you have an AppHost object for every session. Now we need to access the current parameters from the customer record. We do this with the following method:

private Dictionary<string, CRMApplicationData> GetApplicationParameters(string applicationName = "")
    var customerRecord =
            ((AgentDesktopSession) localSessionManager.ActiveSession).Customer.DesktopCustomer;
    if (customerRecord == null) return null;
    if (applicationName != "")
        return customerRecord.CapturedReplacementVariables[applicationName];
    var completeParameterList = new Dictionary<string, CRMApplicationData>();
    foreach (var appName in customerRecord.CapturedReplacementVariables.Keys)
        var appParameterList = customerRecord.CapturedReplacementVariables[appName];
        foreach (var entry in appParameterList)
            completeParameterList.Add(entry.Key, entry.Value);
    return completeParameterList;

This method returns all the existing parameters for the current customer record. We kept it generic so that we can reuse it for any future mad ideas we might have. Now we code in the new event handler for RequestApplicationClose:

private void AppHost_RequestApplicationClose(IHostedApplication app)
    var applicationParameters = GetApplicationParameters(app.ApplicationName);
    if (applicationParameters.ContainsKey("url"))


Now we just look for the parameter, and kill it with fire. That’s it! This executes pretty fast with no noticeable performance hits; remember that this is set to run when the tab is closed, so the user is not left waiting for a process to run. This is a very easy way to remove parameters with pinpoint precision.

Tagged , , , , , , , ,

CRM 2015: Business Rules and JavaScript don’t mix, unless you really like acetaminophen

frustration-600x450_1-100521350-origYep, I said it. And this might be my first real random musing, so bear with me.

In our CRM 2015 implementation with the Unified Service Desk we decided that, for some of the simpler custom entities, we would change the validation from JavaScript to Business Rules. That way we would be able to have an easy way to establish client-side validations and rules, and avoid having to code those rules. We would also have elegant field-level error messages instead of things like pop-ups. Sounded like an ideal thing.

In our real world, unfortunately, didn’t work out that way. Or at least it hasn’t so far.

There’s a few corny things about Business Rules. First, they execute in the order you activate them. Excuse me, Microsoft, but that’s a bit of a bone-headed implementation. That means that developers would need to have a list of the correct order of activation just in case they needed to work with the rules. Why couldn’t they implement a relative sequence number is beyond my comprehension. Hey, they did it with USD window navigation rules!

Second, they need to be defined at the entity level to be executed on save. That means that now you have a process running all the time, every time, for every save you perform in that entity, regardless if you activate the validation only 5% of the time.

Third, as I mentioned above, if you throw JavaScript into the mix, with Ajax calls, XRM, etc… Let’s say it gets really busy. Especially since Business Rules are nowhere as easy to debug and trace as JavaScript validations.

So what’s my final take on all this?

If you have a mostly vanilla CRM implementation, Business Rules might be the thing for you. This carries even more weight if you have Business Analysts putting in validations in your organization. No need to code these is a huge advantage.

However, if you have a highly-modified organization, with lots of heavy XRM, jQuery, and even DOM manipulation, your best bet is to stay away from Business Rules. In our implementation with the Unified Service Desk, where we have custom code for managing tabs in Save & Close, getting the Business Rules to work reliably has been a hair-pulling experience. The time you’ll spend spinning your wheels trying to get things working together is akin to herding cats: you might be able to pull it off, but in the end wonder if it was worth all the effort.

What’s your take on this? I’m interested to read other CRM developers opinion on this.

Tagged , , , ,

USD: How to handle Save & Close without getting a confirmation dialog

In our implementation of the Unified Service Desk, we show each entity in its own separate hosted control and thus, a separate tab. Everything worked perfectly, except that every time we pressed Save & Close, we would get a dialog asking for confirmation before closing the tab. Very annoying, and something that needed to be fixed. After a lot of investigation and considering different approaches, what I will show here is how we finally dealt with the issue.

For our solution we’re taking care of saving the entity through code, and handling the tab close through the USD, which is equivalent to clicking on the tab’s “X”.

JavaScript code used for managing tab closure

The code to handle this should be located in a common JavaScript repository, so that it’s available to all entities. This is all the code needed, so there’s no need to create any new code every time you want to add the functionality to a new service request.

// Execute Save & Close from custom ribbon button, for USD compatibility.
function USDSaveAndClose (context) {
    // Remove and add event to save.
    // Save the current entity.

This first function removes and attaches a function to the OnSave CRM event. Removing and attaching it makes sure that it’s only there once, and avoids repeated execution. There might be a more elegant way to achieve this, but this works and has no performance impact. Note that the function being attached is the next one we’ll take a look at.

The last thing this function does is to save the entity. Note that we’re doing a regular save, and not using the saveandclose parameter.

function FireUSDSaveAndCloseEvent () {

The second function, which is the one fires at the end of the save process, fires a USD Hosted Control event. This is a cool way of pushing events via code into the USD, and works as long as you have an event defined for the current active Hosted Control.

Notice that the event we’re firing, SaveAndClose, is not a standard event. We’ll be creating this event later.

Creating the new command bar button and command

To create the new command bar button, we used the fantastic Ribbon Workbench. If you don’t have it, get it now! Click here to download it from the awesome people at Develop 1.

Create a solution that includes the entities you will be modifying, and don’t forget to include the web resource that contains the code shown above. Now, run the Ribbon Workbench, load your solution, and select the entity your wish to modify. Select the Command Bar at the top right click in the Commands tree node to add a new command.


Now give the command a significant name, something like “publisher.entity.function.Command” works nicely:


Click the lookup button in actions, and add a new JavaScript function. It will have two parameters: the function name (must match the name of the first function shown above), and the web resource it comes from, for which you’ll get a lookup. The end result would be something like this:


Now it’s time to create our own Save & Close button! From the Toolbar area, drag a button to the spot where you want it. We placed ours between the default Save and Save & Close buttons. You’ll need to copy a couple of lines from the existing Save & Close button. I’ve enclosed screenshots comparing between the default button and my new one.

Default button

Default button

New Save & Close button

New Save & Close button

As shown here, I copied the image source paths, and the labels (mostly). In our case, we also need to add the Command that will be run, and it will be selected from the dropdown in the Behaviour section. In this screenshot, it shows in the CommandCore are too because I’ve already saved this record.

Now, hide the old Save & Close button by right-clicking on it and selecting the option from the context menu. Your command bar should look like this:


After you’re done, click the Publish button to make the changes effective.

Adding the custom event and action call

Go to CRM and create a new event for your hosted control, and name it SaveAndCloseThis is the custom event we’ll be firing, and will take care of closing our tab after saving, avoiding any confirmation dialogs from the IE process.


Create a new Action Call for this event, and name it however fits your standards. Reference the standard UII Action Close, which will close the current active tab for this hosted control. It should look like this:


Remember to add these two to the appropriate configurations! That’s all we need! Fire up the USD and test it out. Let me know if you have any questions.

Have fun!

Tagged , , , ,

USD: Missing records when importing with the CRM Configuration Migration tool? Read on!

Microsoft has included as part of the CRM 2015 SDK an application called the Configuration Migration tool. You can find a detailed explanation of how it works in Jukka Niiranen’s fantastic CRM blog.

If you scroll down that article to the subtitle Reviewing the results, you’ll notice that he found some issues initially with the resulting data set. Turns out that the tool uses the Name field as the primary key and unique identifier. With the Unified Service Desk, this will give you a nice, heavy headache when you try to migrate your configuration between development, test, and production environments. Why?

Specifically, two USD entities are the culprits: The UII Action and the Event. These entities repeat the same names by default: PopupRouted, PageLoadComplete, RunXrmCommand, and so on. When you run the Configuration Migration tool with the default settings, you will only get one of each type of entity record. That means only one PopupRouted event, only one RunXrmCommand UII Action…you get the idea.

The solution for this is to make sure that you specify different default fields for identifying unique records for these entities. To enter these specifications, bring up the CRM Configuration Migration tool (found in the SDK Tools folder), and after you connect to your organization and select the USD solution and its entities, select the following item from the top menu.


Here you will see a list of the entities you’ve already selected for the schema. In my case, I only selected the two I need for this example. Stay tuned for the solution to our problem!


To correct the issue with events, we have two choices in our unique record selection. We can either do it by Id…


Or, we can do it by field selection. In the case of Events, we have two fields that uniquely identify each record: Name and Hosted Application.

usd_configure_event_nameAnd that’s all you need! This will bring in each and every record for the Event entity. The difference between these two approaches is that doing it by field value will definitely prevent you from accidentally having records with duplicate values. This applies mostly to development environments where you might be mixing data from other developer machines. But if you have a Master Schema with your current last-deployed work (you do have, don’t you?), then you can be okay with just using the record id.

UII Action

For UII Action, the fix is basically the same as with Event. You can either use the Id…

usd_configure_action_idOr you can use the Hosted Application and Name combination.

usd_configure_action_nameAnd the difference with both approaches is exactly the same as with the Event entity.

Now you will be able to bring in all your USD configuration information painlessly throughout your environments. The Configuration Migration tool is a pretty useful application, and I suggest you take advantage of how easy it is to create export/import schemas and datasets for all your environments, although as they mention, this is more intended for the stuff you have in relation to application configuration and such, and not for user data.

Have fun!

Tagged , , , , , , ,

USD: How to get records of the same type on different tabs?

My apologies in advance because I can’t show detailed screenshots; I work at a financial institution, so you get the drift. I’ll try to be as clear as possible, though.

In our implementation, we need to show different Account records (this is a custom entity, not the CRM default) in separate independent tabs when selected from the Contact form sub-grid. The problem here is that the default CRM behavior is to put all the records in the same tab and then provide a dropdown that allows you to select which record you want to view.

No bueno. So how do you get CRM to show each record in its own tab within the current session?

You need to create as many Hosted Controls for the entity as you might need to show individually. In our case, we’ve determined that users have around three tabs open on average, so we went ahead and created five Hosted Controls for our Account entity. It’s very important that they have distinct names, so they were named “Account 1”, “Account 2”, etc.

Easy enough, we’re halfway there. Here comes the mildly tricky part. You need to create as many Window Navigation Rules as you have Hosted Controls. So that means in our case, five WNRs. Here are the details on what to put in the fields:

  • General
    • Name: Make sure you use a sequence here that matches the HCs description for clarity’s sake.
    • Order: This is crucial. This determines how the USD will go through an elimination process to determine where to pop-up your page.
  • Route Logic
    • From: The entity from where you’ll be showing these records. In our case, Contact.
    • Entity: The Entity Type you will be displaying.
  • Result
    • Route Type: In Place
    • Destination: Tab
    • Action: Route Window
    • Target Tab: The name of the corresponding hosted control. So if this is “WNR MyEntity 1”, the HC would probably be “MyEntity 1”. Something along those lines.
    • Show Tab: Same deal as above, if you want the USD to switch to that tab automatically.
    • Options: Set these two as you prefer.
  • Advanced
    • Condition: This is the cool part. You will type in this:
      • "[[HostedControlName.url]+]" == ""
        • Make sure you include the double quotes as shown.
        • Replace HostedControlName with the name of the HC you will be pointing at, which is the same as the Target Tab above.
        • You will not place the condition in the last WNR. Leave it blank.

How does this work? The USD will check the condition for presenting the record based on the first WNR rule set for the entity. It will check for the URL of the related hosted control. If it finds that it’s blank, it’ll fire this navigation rule and be done.

However, if the URL is not blank, it’ll skip this rule and move on to the next one, which, referencing a different hosted control, will be forced to be displayed in a new tab!

In our internal testing it works flawlessly. No hitches, no performance issues.

But hey, you ask. What happens when we hit the last rule? Then we go back to the normal USD behavior with the dropdown for all subsequent form calls.

That’s it! A million thanks to our Microsoft PFE and CRM guru Daren Turner for providing this solution.

Have fun!

Tagged , , , , , ,

USD: Keeping the Session Navigator open by default

Here’s an easy tip: If you want the Session Navigator (that’s the navigation area on the left-hand side of the screen) to remain open by default, just head to the Custom Panel hosted control, and look for this line:

<Expander Grid.Column="0" Style="{DynamicResource StretchExpanderStyle}"
ExpandDirection="Left" x:Name="ExpanderSessionDetails"
IsExpanded="false" BorderBrush="White" >

And change isExpanded from “false” to “true”. That’s it! Now your Session Navigator will open by default.

Tagged , , , , , ,