Lookup Dialog Investigations

Recently there seems to have been renewed interest in trying to re-use the standard lookup dialogue inside the CRM system in different ways. One of the more frequent requests is to be able to filter the returned records in a custom way, so I decided to see in a bit more detail what the issues were. For example, say you set an account to be the customer for an opportunity and you wanted to select one or more significant contacts within the account as significant relationships (perhaps influencer and decision maker), then it would make sense to just to show contacts for the customer account. Well, you can't!

OK, it didn't take much searching before I found a request to Microsoft posted by Michael Hoehne way back in April 06. Now the definition for displayed entity types, columns and filtering is contained in a number (69) of lookupclass files in the Server\ApplicationFiles folder. Unfortunately, whereas you might think you could just create some more and use those this will invariably lead to a System.IO File not Found error. I even figured that perhaps these needed to be registered in the database. Not so, Michael found there is a hardcoded restriction which apparently is still there in CRM4.0. Of course that opened the door for the Stunnware custom dialog which relies on just this short-coming.

Then (back on our example problem of selecting account contacts for an opportunity) I chanced across an interesting blog by Darren Lui concerning how to invoke the lookup dialog and keep the contact in sync. if we're only interested in a single contact. Unfortunately this doesn't tackle the problem of filtering by account.

During the course of my investigations I did come across a couple of things which mean that the determined developer can achieve something:

1. In fact there is a mechanism for passing in filtering parameters to the lookup dialog - using
   eg. additionalparams = "&customerid=" + crmForm.all.customerid.DataValue[0].id ;
2. Although you can only define one entity columnset/filter per lookupclass file, you can 're-use' non-conflicting' files for other entity types eg. territory.xml contains a defintion for entityid=2013, but not entityid=2 (contact).

In the next installment, I shall hope to show how you can achieve useful custom functionality without 'serious' unsupported customisations.