Using Dialogs to Make a Mechanical Turk

The original ‘Mechanical Turk’ was a machine made in the late 1700s to play chess. Here is the picture from Wikipedia.

I do not think the term was supposed to be racist. I think it was designed to conjure up an image of something exotic and the history of chess is tied to the Middle East (although originally from India). I am guessing, to the European courts of the time, Turkey and the Ottoman Empire may have been the most accessible part of the Middle East and, thus, the connection.

The thing is it was a con. It was an elaborate form of the ‘magic box’ act where a person goes in the box and then disappears. In this case the main doors had cogs and bits and pieces inside them and the cabinet had doors on the other side so you could look all the way through but behind the drawers at the bottom was a hidden compartment to hide a person.

The illusion would involve bringing out the machine, showing the inner workings and then challenge an audience member to play a game of chess with it. Once the doors of the cabinet were closed and an audience member selected, the chess master hidden in the bottom would pop up and control the automaton from within. Generally they won the game and the audience would marvel that a machine could rival a human at such a complex pursuit (even IBM’s Deep Blue had human assistance when it beat Kasparov).

The fact is there are some things which are quite difficult for a machine to do which are easier for a human, and vice versa. In using Dialogs in CRM we can get the best of both worlds.

The Problem

The problem my client had was quite simple but difficult to solve in a completely automated way. The client often attended trade shows. From these trade shows they gathered business cards which they intended to bring into their CRM system. However, their CRM system was integrated to other systems, including their accounting system. While the creation of a duplicate Contact was not a big problem and could be handled using CRM’s merging tools, the creation of a duplicate Account (Organisation) would create new records in the remote systems and more of a headache to unravel.

There simply was no way to guarantee a match to an Organisation in the system, due to loose naming conventions, regardless of the clever rules and code we could throw at the system.

The Solution

In this case, a Dialog proved to be a nice way to work around the problem. First of all the user imports all the Contact records. The import does not populate the Parent Organisation, but holds the Organisation name in a custom field on the Contact (Import Organisation Name). The Dialog was then used to process the records. Just like Deep Blue, I got CRM to do the heavy lifting where it could and when it was not sure, fell back to the user.

Here is the Dialog:

Looking at the header, you will see I have made this a child process. The reason being the Dialog will go through all Contacts which need an Organisation one at a time and call itself to process the next one. Unlike Workflows, there does not appear to be any problem writing a potentially infinitely looping Dialog.

To call the Dialog, the user simply finds a record they have just imported and runs it from this. The Dialog then uses the ownership information of that record in the first query which, essentially, finds all Contacts where the Import Organisation Name has a value but the Parent Organisation field does not.

The results are then presented to the user in a Page and the user selects the record they wish to process.

A secondary query is then run to try and find a matching Organisation. In this case the query looked for all Organisations in the system where the Organisation Name began with the value of the Import Organisation Name of the selected Contact. Two scenarios then ensue:

• There are no matches: In which case the system automatically creates a new Organisation, links the selected Contact to it and calls the Dialog again for the user to select a new Contact
• There is one or more matches: With no hope that CRM can work out which one, all are presented to the user, who selects one. Once selected, the Contact is linked and the Dialog called for the selection of another Contact

So it continues until the user gets through all the Contacts or gets bored and cancels the Dialog knowing they will revisit it later.

I did also add an additional option to the second scenario or presenting a two value question to cover if none of the Organisations presented are a good match. In this case, as with the first option, a new Organisation is created.

Conclusions

Since using this trick a few months ago, other uses have come up, such as for processing event registrations via web forms and newsletter subscriptions. I still hope that things like Queries, Input Arguments and Variables will eventually come to Workflows but, until then, do not discount Dialogs as simply good for call scripting. They are powerful and, like the Mechanical Turk allow us to supplement the limitations of technology with the human factor.