Pseudo-Filtered Lookup Dialog in Microsoft Dynamics CRM 4.0

One of the great unsupported customizations in Microsoft CRM 3.0 was the ability to apply a filter to a lookup with just a few lines of JavaScript.  Ronald Lemmen had a nice post describing this approach that used a FetchXml query to filter the lookup values.  However, in Microsoft CRM 4.0 this customization no longer works and when you attempt it you receive the following depressing error:

CRM Parameter Filter - Invalid parameter 'fetchXml=...' in Request.QueryString on page /_controls/lookup/lookupsingle.aspx

Figuring Microsoft must have renamed the parameters I spent some time today scanning the Microsoft CRM DLL files (Lutz Roeder's Reflector for .NET is a great tool for reverse engineering).  Unfortunately I came up dry and have come to the conclusion this approach no longer works.  Hey, it was unsupported in the first place -- can't really complain ;-)  Since filtering is such an important feature of usability we still wanted to find a way to apply a filter to lookups.  In our world we have relationships where entity names are not always unique across the organization, though they are unique within the context of their parent relationship.

Of the query string parameters still available one still gave promise of a possible solution - search.  When this parameter is specified it defaults the search string in the lookup dialog and applies the search when the dialog is opened.  While we are not able to target our filter to a specific field, we can still leverage the lookup search (and the search columns for the lookup view) to filter the records returned.

For this example assume we have two entities - state and city - with the state being the parent of city.  In the City Lookup View add a find column for the state name:

In the onload event of the form we add the following:

document.FilterLookup = function(source, target)
{
    if (IsNull(source) || IsNull(target)) { return; }

    var name = IsNull(source.DataValue) ? '' : source.DataValue[0].name;

    target.additionalparams = 'search=' + name;
}

In the onchange event of the state field on the form we add the following:

document.FilterLookup(crmForm.all.awx_stateid, crmForm.all.awx_cityid);

When the user selects a state...

... and then chooses a city, they see this:

Filtered?  Yes!  Supported?  Maybe not, but should be good until 5.0 :-)

Extending duplicate detection with Soundex

The duplicate detection included in Microsoft CRM 4.0 is great.  It provides a foundation for creating a variety of rules to detect duplicate records using "like" matches across multiple entity types.  However, "like" matches can start to breakdown when the spelling of names differs, which often occurs with proper names.  This article describes how to extend the duplication detection in Microsoft CRM 4.0 to include "fuzzy" matching based on the Soundex algorithm.

The Soundex algorithm converts a name into a four-character string, originally used for indexing, that can also be used for comparisons.  In Microsoft CRM 4.0 to implement Soundex duplicate detection we created a new field on the entities to be compared for storing the Soundex value and added JavaScript to the "onChange" event of the name field to store the value.  The steps involved are:

1. Add "Soundex" attribute to your entity
   
    
2. Add "Soundex" attribute to your form (set as read-only).  This step helps illustrate the example, validates the logic is working correctly, and makes the field available to the JavaScript in step # 3.  However, it is probably best not to display this value to the user and it could be hidden as described here on Ronald Lemmen's blog.
   
   
    
3. In the "onLoad" event set the ForceSubmit flag to true for the Soundex field
   
   
    
4. Apply "onChange" event to the primary name attribute using JavaScript such as the code found here to set the value of the Soundex field.
   
5. Create a new duplicate detection rule comparing the Soundex values
   
   
    

Once everything is in place, if you create an account named John's Bait Shop and try and create a new account named Jon's Bait Shop the duplication rules will detect a potential duplicate and alert the user accordingly.

What we found is not only is this rule effective in finding potential duplicates, but if Soundex rules are in place there is not really a need to use "like" matches based on the the primary field.  Once the Soundex values are in place they can be used across entities like other duplication rules.

It is worth noting the "onChange" event only fires when the data is input via the standard UI.  It is probably better to apply the Soundex logic via a server-side callout, but for the simplicity of this example we are just demonstrating a client-side approach.

3 Click Rule

One of our primary design tenants is to make the use of our products a pleasant experience. The definition of pleasant is subjective, but it can also be quantitative when you think about how easy (or difficult) is it for a user to complete a task. This is where we apply the 3 click rule, meaning "that access to any feature of an application, or each logical step in a process, should require no more than 3 clicks."

With Microsoft CRM it is often noted how clicky it is to use.  To view details about an entity, the user must:

1. Select the entity type from the navigation bar
2. Locate the entity in the grid
3. Select the entity in the grid
4. Open the entity
5. Navigate to the tab containing the details

Minimum of 5 clicks (but likely more)

If the user then wants to see details on another similar entity, the user must:

1. Close the open form
2. Locate the entity in the grid
3. Select the entity in the grid
4. Open the entity
5. Navigate to the tab containing the details

Minimum of 5 clicks (but likely more)

So, how do we improve the user experience?  One solution we offer our clients is our Split View component.  The Split View allows the user to view entity details without the need to open the entity for edit.  The Split View can also display extended information from related entities, incorporate our Relationship Navigator, and supports the addition of custom panels to meet other business needs.

Let's look at the above scenario again.  To view the details about an entity, the user must:

1. Select the entity type from the navigation bar
2. Locate the entity in the grid
3. Select the entity in the grid

Success!!!  3 clicks.  The Split View does the rest!

If the user then wants to see details on another similar entity, the user must:

1. Select the entity in the grid

Success!!!  1 click!!

While it may not seem like much, getting from a total of 10 clicks to 4 clicks is a 60% savings.  The result is not only a reduction in the number of times the user has to click their mouse button, but also the amount of time the user must wait for additional dialogs to load.  In addition the server load is reduced, which has a secondary benefit of quicker response times -- again improving the user experience.  When the number of entities viewed grows to three the savings increases to 66%, and at five entities viewed the savings is over 70%.

This is a simple scenario, but it demonstrates the impact the 3 click rule can make to the user.  Keeping the end user in mind during design increases user adoption during deployment, which results in a higher ROI -- and that translates into a happy customer, our ultimate goal.