Sunday, January 18, 2015

An Improved Codeless Address Finder

Back in 2011, I showed how, by using filtered lookups, it was possible to make an address finder. While instructive in showing how filtered lookups worked, one shortcoming in the approach was that the address fields had to be replaced with lookups. For the Contact record this is problematic because the address fields synchronize with the Outlook Contact address fields. This means that if the user tracked a Contact from Outlook, in effect, the address would not come across.

I thought I would revisit the design, using the improved workflow functionality to see if we can do better in CRM 2013/2015, inspired by something I saw in a client’s system.

The Inspiration

For the last couple of weeks I have been conducting workshops with a client for implementing a new Dynamics CRM implementation. While they have an existing ‘proof of concept’ system built in CRM 2011, it had been added to incrementally and, so, they wanted to re-build from a blank slate. In looking at screenshots of their old system I noticed a ‘Location Lookup’. Basically you lookup a location and it populates the address fields for you.


I did not look into the back end of how it worked but my guess is some OnChange jscript does the heavy lifting. What is nice about this design is it gets around the issue with the Outlook client; if the user tracks a Contact, the address fields still populate. It is only the location lookup which is left blank, but this is ok.

Replicating in CRM 2015: Reference Data

The first thing I needed was a list of the cities, post codes and states for Australia. Fortunately I still had the old CSV files from my first blog, which was lucky because Australia Post charge to get them these days (they used to be free). If you are interested in Australia city data, a quick search yielded this, which also has longitude and latitude coordinates and appears to be free to use.

I combined the information into one CSV (we are only doing one import this time).


Next, I needed an entity to hold the reference data. I created one with the default name field and a text field for each of the above called Reference City.


The Name field I populated with a background workflow which ran during the import.


Then I ran the import to create my reference data.

Replicating in CRM 2015: Setting up the Location Field

The Location field is actually pretty easy to set up. Firstly, you add a lookup, on the Account form pointing to your Reference City entity. Then, you add the real time workflow which does the work.


The field change is set to trigger off of the Location lookup field we added. You also need to run it off of the Record Created event otherwise it does not trigger for the creation of new records.

The Result

The end result is reasonably close to the original. The only difference is it shows on the form OnSave, not OnChange, so the address fields remain blank until you save or until the AutoSave kicks in. I tried ‘fixing’ this by adding a Business Rule to the form but it did not work. Something to watch out for but nothing that could not be handled as part of training. The first screenshot is actually my version of the Location Lookup and here it is again.



I really like this approach. It is codeless and completely extendable. If you had street data, you could extend the solution to accommodate this without too much difficulty (although be careful of the size if you are using CRM Online). It also keeps the original address fields, which gets around Outlook sync issues, Word template issues and Bing Map integration issues. If you are a consultant, this is simple to put together, offers a lot of value to clients and does not rely on expensive, third party address software.

No comments: