Case Number is Just the Ticket
Today’s guest blogger is the technical director of AlexaCRM™ and CRM MVP George Doubinski. Follow him at his blog, Georged CRM Blog.
Microsoft Dynamics CRM has a number of entities that, in addition to the record id (represented by GUID data type in the system), also contain unique text identifiers that can be automatically generated by the platform. There is a common misconception that the way these numbers are generated is cast in stone and users just have to “live with it”.
Out of the box, system administrators have somewhat limited control over the automatic generation of these numbers using Settings->Administration->Auto-Numbering dialog.
Quite often CRM algorithm for auto-generated numbers for these entities is acceptable, but occasionally there is a need to generate identifiers according to the pre-existing business rules or even let users to enter the numbers. The latter was just the requirement in one of our projects where we were asked to allow end-users to enter custom numbers when creating new cases.
For the case entity (called incident in the system) case numbers are stored in the attribute ticketnumber which is an nvarchar(100) field. By default, this attribute is not event on the form but is displayed in the form header after the case record is created:
Our first stop is Microsoft Dynamics CRM SDK information for the ticketnumber attribute:
Note that Valid for create value is Yes meaning that we can actually set this attribute when creating new record. Valid for update is set to No which tells us that, once the case record is created, it’s no longer possible to change the case number.
If we simply add ticketnumber attribute to the form, it comes up as a read-only thanks to the default script for the case form. The solution is very simple – just add the javascript code below to the form onLoad event to make sure that the field is not read-only for create and quick create forms.
var CRM_FORM_TYPE_CREATE = 1;
var CRM_FORM_TYPE_QUICKCREATE = 5;
if(crmForm.FormType == CRM_FORM_TYPE_CREATE ||
crmForm.FormType == CRM_FORM_TYPE_QUICKCREATE)
{
crmForm.all.ticketnumber.Disabled = false;
}
The result is that users can now enter custom numbers when creating cases and system will generate the number if user does not enter one.
Unfortunately, if users enter a case number that already exists in the system, they will receive a generic error message that does not explain what happened. One possible solution is to create a synchronous precreate plugin that would ensure that the case number entered by the user is unique and return a custom error message if it is not.
The plugin is also a solution if case numbers need to be generated automatically. In this situation plugin can detect null case numbers (i.e. nothing has been entered on the form) and generate a new number as required by the business. If plugin does not create a case number, platform code will take care of it using a built-in algorithm.
The described approach can also be used for contract and campaign entities as well. In fact, campaign entity form already contains attribute codename (labeled Campaign Code on the form) which can be entered by the user with platform code generating the value if user does not enter one. And as before, using a plugin to provide custom numbers is just the ticket.
Happy coding!
