Why is *.number not unique by default?

[johnsgp]

I have noticed numerous questions in the forum about duplication of incident numbers, task numbers, CI numbers, knowledge numbers, and so on.

Often these questions involve discussions of fix scripts that are not quite working.

One of the more interesting comments is in Re: Duplicate incidents are created with same incident number but different sys_id? where Mack Peace wrote:

This issue is caused when users double click the "Submit" button.   From what I understand this is a known issue and the way to prevent it is to make the ticket number "unique".

It seems to me to be an unnecessary leniency to allow duplication in what should be a key field. In particular, task.number (and all its inherited tables) and kb_knowledge.number as a minimum should be unique in all new instances to ensure that the double-clicking of the Submit button issue is addressed.   I understand that older instances might not easily be upgraded to uniqueness due to existing duplication, so I do not expect these to be upgraded automatically.

Does anyone know why the number fields are not unique by default in new instances?  

[Brad Tilton]

I'm not quite sure what the reasoning was originally for number fields not being unique, but there is a use case where you may end up with table sharing the same prefix and have duplicate numbers. They could be in different task extended tables, so there would really be any collision, but since they're extended from task and number is on task, uniqueness would cause issues. I don't think this is a great practice, but I have seen it happen.

Here's a wiki article on adding uniqueness to the number field.

Creating New Fields - ServiceNow Wiki

[johnsgp]

Hi Brad, thanks for your reply.

I can understand such a use case, but I cannot understand why new instances cannot have uniqueness by default.   Anyone with use cases such as the one you described can easily remove the uniqueness constraint, while being forced first to understand the down side.   The majority (I expect) of users will have no negative effects, only the positive of avoiding duplication.

It is easy to remove a uniqueness constraint.   It is difficult to add it once the data is duplicated because you have to clean the data first.   This not only involves writing a script (thus means having/buying JavaScript skills) but also getting agreement on how to deduplicate (is it by merge/delete, by renumbering, or other? if renumbering how will it be renumbered - by adding a prefix, by taking a new number from the end of the sequence, or other?     how will merge/delete or renumbering be auditable, affect prior reports, etc -- it's big).

[Kalaiarasan Pus]

It could be because no one actually submitted this as a enhancement. You may try submitting one and share the official response here

But I agree with what you are saying, "it is easy to remove uniqueness but difficult to add it"

[vinothkumar]

Hi John,

I also have the same question and have you got any response with Hi Support?