Activity coding in Dynamics CRM

by Lucas Alexander

At a previous job, we had used GoldMine (version 6.7 was where we parted ways) as our CRM system before moving to Dynamics CRM. At the time - maybe it's still done this way - GoldMine allowed you to code activities with a hierarchy of references, codes and results. We used reference to separate activities either by department or broad functional grouping (e.g. "service" was a separate reference although there was no separate "service" department). Codes were the specific kinds of activities or client touch points grouped under a reference, and the results indicated how the activity concluded.

The reference/code/result structure allowed us an incredible level of granularity for tracking all the times we either interacted with an external stakeholder (client, prospect, partner, external service provider) or did something on its behalf. We were able to compile detailed "production" reports for our call center reps, and the activities' structure gave them a framework for approaching their routine daily responsibilities.

Here's a simple reference/code/result example:

  • Reference - Sales
  • Code - 1PC//Prospecting call_ (In GoldMine everything before the // was treated as the picklist entry's primary key, so the 1PC would be stored in the database. We would then speak of 1PC calls as a shorthand.)_
  • Result - 1LM//Left message

We tracked everything this way. Despite us still using GoldMine 6.7 in some parts of our business all the way into 2008, activity tracking was great except for two problems. First, although the codes existed in our processes as a logical hierarchy, GoldMine didn't understand that. If you picked the "sales" reference, you still had to weed through all the codes and results that corresponded to all the other references. Second, adding new reference/code/result entries in a supported manner took a lot of time.When we started considering the move to CRM 3 in 2005, I found the default activity entity structure to be something of a letdown, so I brought the reference/code/result framework over when we actually did move. Here's how I did it.

First, I created three separate picklist attributes in CRM on the six main activity entities we used - appointment, e-mail, fax, letter, phone call and task. Let's call them lucas_reference, lucas_code and lucas_result. I then populated them with the existing references, codes and results from GoldMine. The following are not the actual codes, but they'll give you a decent idea of how things were structured.

References (lucas_reference)

Sales

Service

Codes (lucas_code)

1CD//Contract discussion

1PC//Prospecting call

1PE//Prospecting e-mail

1FC//Follow-up call

1FE//Follow-up e-mail

1SC//Suspect call

2CI//Service call inbound

2EI//Service e-mail inbound

2FU//Service follow-up

Results (lucas_result)

1CF//Contract finalized

1UP//Understands product

2CS//Customer satisfied

2CU//Customer unsatisfied

2IE//Issue escalated

2IR//Issue resolved

CRS//Call rescheduled

CMP//Completed

EMI//E-mail in

EMO//E-mail out

PCI//Phone call in

PCO//Phone call out

LVM//Left message

In this example, codes and results starting with 1 are children of the "sales" reference. Codes and results starting with 2 are children of the "service" reference. Codes and results starting with letters are general options available to any reference.

At this point, allow me to point out a few things. First, we didn't use the existing CRM service activity, and we rarely (practically never) used the fax or letter entities. Why we didn't is beyond the scope of this blog post.Second, the reference/code/result picklist entries were duplicated across all six activity entities even if they didn't make sense. That is, you could have a task with a result of "PCO//Phone call out." Because we had several hundred options, it was easier to make sure every activity had everything than to weed out the ones that didn't fit. Also it made report writing simpler.Third, the general options were handy for when we didn't have a firm process that applied to the activity. For example, sometimes on the service side, all we could do was note that a call came in.Fourth, reference and code were business required. Result was not because you obviously wouldn't know a scheduled activity's result at the point in time when you created it.

Once I created and populated the picklist attributes, I added them to the entities' forms, which was simple enough, but you'd still have the GoldMine problem of every code and result being available for any reference. I took care of that with a bit of JavaScript.The following example is based on something I picked up from "Working with Microsoft Dynamics CRM 3.0" by Mike Snyder and Jim Steger.

var objRef = crmForm.all.lucas_reference;  
var objCode = crmForm.all.lucas_code;  
var objRes = crmForm.all.lucas_result;  
  
//get the currently selected code and result values so we don't lose data if we're editing an activity instead of creating a new one  
var curcode = objCode.DataValue;  
var curresult = objRes.DataValue;  
  
//set the lucas_code and lucas_result picklist options to empy arrays for now  
var oTempArray = new Array();  
objCode.Options = oTempArray;  
var oTempArrayRes = new Array();  
objRes.Options = oTempArrayRes;  
  
//if a reference is selected  
if(objRef.SelectedText!="")  
{  
//get prefix of codes we're going to enable  
var codePrefix = "";  
var resPrefix = "";  
switch(objRef.SelectedText)  
{  
case "Sales":  
codePrefix = "1";  
resPrefix = "1";  
break;  
case "Service":  
codePrefix = "2";  
resPrefix = "2";  
break;  
}  
  
//enable the correct code codes  
if(codePrefix != "")  
{  
//loop through the original lucas_code options  
for (var i = 1; i < objCode.originalPicklistOptions.length; i++)  
{  
//if the lucas_code option begins with the codePrefix, add it to the holding array  
if(objCode.originalPicklistOptions[i].Text.indexOf(codePrefix)==0)  
{  
objCode.AddOption(objCode.originalPicklistOptions[i].Text, objCode.originalPicklistOptions[i].DataValue);  
}  
}  
  
//make sure the picklist is enabled  
objCode.Disabled = false;  
  
//set the picklist's selected value to what we stored earlier  
objCode.DataValue = curcode;  
}  
else  
{  
//disable the field  
objCode.Disabled = true;  
}  
  
//enable the correct result codes  
if(resPrefix != "")  
{  
//loop through the original lucas_result options  
for (var j = 1; j < objRes.originalPicklistOptions.length; j++)  
{  
//if the lucas_result option begins with the resPrefix, add it to the holding array  
if(objRes.originalPicklistOptions[j].Text.indexOf(resPrefix)==0)  
{  
objRes.AddOption(objRes.originalPicklistOptions[j].Text, objRes.originalPicklistOptions[j].DataValue);  
}  
//handle some general cases  
if(objRes.originalPicklistOptions[j].Text.indexOf("CRS")==0)  
{  
objRes.AddOption(objRes.originalPicklistOptions[j].Text, objRes.originalPicklistOptions[j].DataValue);  
}  
if(objRes.originalPicklistOptions[j].Text.indexOf("CMP")==0)  
{  
objRes.AddOption(objRes.originalPicklistOptions[j].Text, objRes.originalPicklistOptions[j].DataValue);  
}  
}  
  
//make sure the picklist is enabled  
objRes.Disabled = false;  
  
//set the picklist's selected value to what we stored earlier  
objRes.DataValue = curresult;  
}  
else  
{  
//disable the field  
objRes.Disabled = true;  
}  
}  
else  
{  
//no selected reference, no displayed codes or results  
objCode.Options = oTempArray();  
objRes.Options = oTempArrayRes();  
  
//disable the fields for good measure  
objRes.Disabled = true;  
objCode.Disabled = true;  
)

Add that to the onLoad event for each activity form and the onChange event for the reference field on each activity form, and you're good to go.

Happy activity documenting!