Sunday, August 11, 2013

Using Dialogs When a Contact Moves Employers

A common scenario when maintaining Contacts in a CRM system is moving them between employers when they change jobs. For Dynamics CRM, and many other CRM systems, this poses a problem: what happens with their Activity history?

If we simply click on the Parent Customer lookup and change the Account, all the Activity history moves with them to the new Account. This may be appropriate for B2C companies, where the history needs to stay with the individual but for B2B this means if I look at the Related ‘Regarding’ Activity summary on the former employer, all the Activities of my Contact has disappeared (now appearing on the rollup of their new employer).

The Solution

The solution often employed is to create a copy of the Contact under the new Account and deactivate the old Contact. This way, while the old Contact will be hidden on the old Account, all their Activity history will still be visible on the Account’s ‘Associated’ Activity. New Activity will be logged against the new version of the Contact and will appear under the Related ‘Regarding’ view of the new Account.

The Problem

The problem is the process for moving the Contact becomes a bit of a chore because we must:

  • Create a ‘clone’ of the old Contact copying across the values of the key fields on the old Contact form
  • (optional) Link the clone Contact with the old Account to state it was a former employer
  • Deactivate the old Contact

It is easy for a user to mistype information when creating a copy of the Contact or to forget to deactivate the old Contact.

The Solution to the Problem: Dialogs

Dialogs provide a way to automate the steps which a user could forget or get wrong and only get from them the information needed.

Here it is:


Step One: Ask for the new Account

The only piece of information we need from the user is the new Account the Contact is moving to. Everything else we can determine from the Contact we start the dialog from.

Here is the Prompt and Response:


The trick here is in setting up the Reference Entity and Reference Field correctly. Thanks to Richard Knudson for his excellent article walking through this. Richard also has a book devoted to CRM Processes so if Processes are a big part of your administration of CRM, it may be worth picking up.

Essentially, the way to set up the Reference Entity and Reference Field is to use a lookup which already exists somewhere in CRM. In this case I have told it to use the Parent Customer lookup on the Contact form. This means, when the dialog runs, I will be able to use this lookup to select an Account as if I was selecting an Account for a Contact on the Contact form.

Step Two: Clone the Contact

This is another handy use of workflows or dialogs: to make a copy of a record. Using the Create Record step, we simply populate the desired fields in a new Contact record.


The only real trick here is using the value we got from our Page and Response to populate the Parent Customer field.

Step Three: Create a Connection back to the old Account (optional)

In this case we link the new clone to the old Account and use the out of the box Former Employer/Employee roles.


In the above picture you can see that to populate the Name field with the right Contact reference, you drop down the Look For in the Form Assistant and find the Page and Response description reference.

Step Four: Deactivate the old Contact

The final step is to deactivate the old Contact which we do with a Change Status step (if you try to use an Update Record step, it will fail).

The End Result

The end result is a dialog we can trigger from any Contact which prompts us for an Account and then takes care of the rest.



Again, Dialogs prove to be more than just a call scripting engine.In this case we take a process which a user could easily make a mistake with and automate it, taking from them only the information required and automating the rest.

If you have processes in your CRM system which have multiple steps and are prone to errors, a Dialog to guide the user through the steps and automating it as much as possible is worth the consideration.


Leon Tribe said...

Hi David,

If we just move the one Contact across to the new Account, all their Activity (emails, appointments, phone calls etc.) will appear under the new Account's Activity summary. For B2B businesses this is generally undesirable.

To get around this, we create a new version of the Contact and leave the original where it is. The Connection is there to tell us the new Contact used to work at the old organisation.

George said...

Clever approach but I'm not convinced it's going to work well if contacts are synchronized with Outlook. You will end up with a duplicate that's going to drive you insane when trying to compose email to that contact. I can see emails flying out to the wrong address, that's for sure.

Leon Tribe said...

Hi George,

You'd certainly need to test it out if you have frequent movement of Contacts and are using Outlook sync.

I'm thinking you might be able to adjust the group filters to help with the Outlook sync and make the dialog blank out the old email address to stop emails going to the wrong place or filter to only send to active Contacts.


Unknown said...

Great idea.
Whether or not you want to duplicate the contact, the beauty of this approach is that you can construct the dialog to do many different things.. And, you can ask the user the questions, that your org wants to... I could see using this to ask them if they want to reassociate old activities to another contact at the old org, e.g. as a way around creating the duple contact. Could show a list of other contacts. If they don't want to re-associate, then create dupe and take away info from the old one. (BTW, if you DO create the dupe, you'll definitely want to clear the email on the original.. otherwise outlook will find two that match and not auto link..