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 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 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.