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.



if(crmForm.FormType == CRM_FORM_TYPE_CREATE ||



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!

George Doubinski

Comments (10)

  1. David Allen says:

    Are such text fields available on activities and other entities?

  2. In the post I targeted text fields where CRM generates the content automatically. This process is hardly documented and people are under impression that it’s impossible to change it which is not entirely true.

    The other thing I did not mention is that quite often these text fields receive somewhat special treatment from CRM, eg. out of the box cases can be searched by the case number etc.

    The entities with auto-generated fields are contract, incident, kbarticle, quote, salesorder, invoice and campaign. Perhaps, we can also add email tracing token into this mix.

    As far as other entities are concerned, nothing is stopping you from adding text fields of your own and generate content automatically by using plugins.

    Hope this helps,


  3. Tom says:

    Just a heads up, Quick Create forms were dropped in 4.0, so the code above can be shortened to just work on the Create form type 1.

  4. hana says:

    How can I populate the case number on the master case? I created a field, however I do not know how to push the number that dispalys on the header to the custom field within the record.

  5. georged says:

    If you add case number to the form and make it read-write as described then you don’t need a custom field within the record. Note that case number is write-once and cannot be changed after the case is created. Whatever you see in the header is the content of ticketnumber attribute, whether created by the user or by the system (if user does not enter any value).

    Does it answer your question? If not then could you please rephrase as I’m not sure I understood all of it, e.g. master case?

  6. Amr99 says:

    How can I add (if is possible), personal entities in this screen?

  7. Dav says:

    How can I add an automatically generated case number to the form title of a newly created entity.  

  8. georged says:


    For custom entities you’ll have to create your own  "number" attribute and implement your custom auto-numbering scheme.


    Not sure I understand. Case number (which could be any string) is automatically displayed on the form title as well as in the header right under the toolbar, as can be clearly seen on the images above.

  9. sagar says:

    why cant we increase the number size ?

    Why prefix and suffix is mandatory ? Isnt it strange it have them mandatory ?

    How about generatin such series












    Is this possible ?

  10. Indie.Dev says:

    Hi George, Very helpful blog. I have a question, if I register plugin on pre-operation my plugin is not able to udpate the case number (no exception is thrown either) and system generated number is assigned to the ticket number field. If I register the plugin at pre-validation, plugin is able to update the ticket number field but in pre-validation stage plugin is not able to run under transaction and this may create a situation of having duplicate case numbers.

    Do you have any suggestions on this.


Skip to main content