Implementing a Change Request System within CRM
Change, as you know, is inevitable; and nowhere more so than within a Microsoft Dynamics CRM system. We have found that the more people use CRM the more they unlock its potential and the more they would like it customized to better fit their methods of work.
After completing several CRM installations this year, I began to realize that my life would be much simpler if I implemented a change management system at each of my customer’s locations to better track individual requests by company. Instead of receiving emails and phone calls, I will now have a user complete a change request within their own system. Today we’ll explore the solution I created based on Change Request documents found in the CRM Implementation Guide.
As you can see from the following figures, the implementation is fairly straightforward:
I was able to use many of the built-in features of a CRM entity such as the following:
- CreatedBy was renamed to Requested By
- CreatedOn was renamed to Date Reported
- Owner was renamed to Assigned To
Actually, the only difficult part of the entire solution was in the definition of the Change Number field. If you do not resort to using an incremental database field, the easiest method for creating a unique number is to use the current date and time. The following Javascript code creates and populates the Change Number field when a new Change Request is created:
/* OnLoad Event */
/*
* Zero-pad a number if the value is less
* than 10.
*/
function ZeroPad(st)
{
var temp = “”;
if (st < 10)
{
temp += ‘0’;
}
temp += st.toString();
return temp;
}
/*
* Build a new Change Number based on
* the current Date and Time.
*/
function BuildChangeNumber()
{
var currentDate = new Date();
var currentDay = currentDate.getUTCDate();
var currentMonth = currentDate.getUTCMonth();
var currentHour = currentDate.getUTCHours();
var currentMinute = currentDate.getUTCMinutes();
var currentSecond = currentDate.getUTCSeconds();
var tempDate = currentDate.getUTCFullYear()
tempDate += “.”;
tempDate += ZeroPad(currentMonth);
tempDate += ZeroPad(currentDay);
tempDate += “.”;
tempDate += ZeroPad(currentHour);
tempDate += ZeroPad(currentMinute);
tempDate += ZeroPad(currentSecond);
// alert(tempDate);
return tempDate;
}
var CRM_FORM_TYPE_CREATE = 1;
/*
* If this is a New record, then populate the
* Change Number field.
*/
if (crmForm.FormType == CRM_FORM_TYPE_CREATE)
{
crmForm.all.new_changenumber.DataValue = BuildChangeNumber();
}
Security Considerations
After you have imported and published the new Change Request Entity, you may need to decide where it should be displayed and who should see it. In many cases, you probably only wish the owners or managers to be able to enter change requests. After you make that determination, you’ll need to edit the Security Role for those individuals and set appropriate security, as shown below:
Putting Change Requests to Work
After you’ve decided who can enter Change Requests, you need to conduct a little training to make sure everyone is comfortable with the new system. Just so you don’t miss anything, you can also create a workflow rule that emails you each time a new Change Request is created:
Conclusion
Well, that pretty much wraps things up. This entire solution only took me about an hour to create and most of that was spent on the Javascript code. I implemented the solution on my own CRM system and find it convenient to make notes regarding changes to Views, Forms, and Reports that I might need. That way I don’t forget and I can perform my changes in a batch rather than one at a time.
