USD – Load two tabs for account (v2)

December 1, 2015

In Unified Service Desk (USD) I had a requirement to always load the account and primary contact details in one step.

In an earlier process I described a simple way to load two tabs, one contained the account and the other contained the primary contact for that account. Prefect!

My previous approach was to simply create an action to load the primary contact, with a condition to confirm a primary contact existed. Then I added this action to the BroswerDocumentComplete event of account. Meaning whenever an account was loaded I loaded the primary contact. It worked well and was very simple to achieve.

But I was never happy with how the approach as it failed to trigger a window navigation rule so I had little or no control on how the contact tab behaved. Not so perfect!!

I have now solved this problem, this post describes how.

The downside is that this solution is more involved but it is more elegant.

I’m going to assume you already understand how to create sessions etc. And that you have a working account session already. Then the steps are as follows;

Create a search for primary contact and an action trigger the search.
Create a hosted control for primary contact.
Create a window navigation rule.
Test the solution.

STEP ONE – Create a search for primary contact and trigger from account.

Within the search options of Unified Service Desk settings create a search to find the primary contact. This is a simple piece of fetch xml that includes a replacement parameter to inject the ID of the primary contact on the account. (Your application may already include this, mine did!)

<fetch version="1.0" output-format="xml-platform" mapping="logical" distinct="false">

<entity name="contact">

<attribute name="fullname" />

<attribute name="telephone1" />

<attribute name="contactid" />

<attribute name="emailaddress1" />

<attribute name="address1_postalcode" />

<attribute name="address1_stateorprovince" />

<attribute name="address1_city" />

<attribute name="address1_composite" />

<order attribute="fullname" descending="false" />

<filter type="and">

<condition attribute="contactid" operator="eq" uiname="[[account.primarycontactid.name]x]" uitype="contact" value="{[[account.primarycontactid.Id]x]}" />

</filter>

</entity>

</fetch>

Now you will need an action to call the search. Mine looked like the one below. Notice that the action is “DoSearch” and that the hosted control is my global manager. The data portion contains the name of the search you wish to trigger.

This action is then added to the BrowserDocumentComplete event of the account, meaning that whenever the account tab is loaded the action will be triggered. Mine is below, you can see that I have included the search for primary contact. (Along with a few other actions to load my agent script etc.)

STEP TWO – Create a hosted control for primary contact.

Initially I used my existing contact hosted control. But this proved problematic in my particular application! The reason being I had existing logic associated with loading the contact tab which conflicted with what I was trying to achieve here. So I got round this by creating a fresh hosted control just for this specific purpose.

Tip: The reason I did this is was I wanted to ensure the account tab kept the focus on the load of the session. And in “background” a second tab loaded containing the primary contact. Using my existing contact tab triggered further actions which wouldn’t allow this.

My hosted control looked like the one below. Nothing unusual! The USD component type was “CRM Page” and I decided to make the Display Group MainPanel.

STEP THREE – Create a window navigation rule.

Next I created a window navigation rule. (the missing element in my previous approach!) This rule is triggered from a search, the search being the one we created in step one.

Route type is set to “OnLoad”, meaning that when the search loads something this rule is triggered.
The field is set to the ID of the primary contact returned by the search.
Destination is tab, as I want to load the primary contact tab.
Action is “route window”, as I’m adding the primary contact tab into the account session.
The target tab is “Primary Contact”, this being the hosted control we just created.
And the showtab is account, as in this example I didn’t want the focus to move to the contact tab.

NOTE: If you also have a contact session in which someone could open the account you might hit a problem! I found that when I open the account from the contact it will open the primary contact. Poor as then I have the contact open twice. if you hit this you can solve the challenge by adding a condition to the window navigation rule to check the context of the search. So adding a condition of “[[$Context.InitialEntity]]”==”account” will mean the primary contact will only be displayed when required.

STEP FOUR – Test the solution.

You can see below that when I tested the solution both the account and its primary contact are loaded. But if I load an account without a primary contact the search returns no results and therefore the contact tab doesn’t load.

Of course there is still a downside of this approach! Loading the session takes longer as the account and contact details need to be loaded. If your users routinely need to review both records then this approach could give benefits but you should be mindful of the impact on performance. In my final solution I have actually created a user option to allow the feature to be activated based on user preference!