duplicate incidents with same number but different sys id ?

[sukran]

Hi,

We are finding duplicate incidents created with same numbers. and I found there is a OOB unique option. Setting unique to true on number field will solve that issue? and does anyone have any idea what is the root cause of this issue?

Number is same and all fields values also same but different sys id 

[Mark Roethof]

Hi there,

Could be multiple reasons. For example, look at the number record. What is the current count, has this count manually been changed at some point? Are there already tickets from the past with higher numbers? Migrated data? Tickets created through script or integration, with autoSysFields(false)? Etc..

If my answer helped you in any way, please then mark it as helpful.

Kind regards,
Mark
2020 ServiceNow Developer MVP

---

LinkedIn

[sukran]

Answering your ques

Current count - only 2 incidents were created with same time (Time - 09:34:52 and 09:34:55)

Not manually changed - INC field is read only 

Its looks like manually creation ,not by inbound or script 

This incident reported recent issue , not past higher number or migrated data

[asifnoor]

Hi Sukran,

Were you able to replicate the issue or is this one off issue? Go to number maintenance and check the count and compare with the incident record. Most probably this could happen if both got created at the exact same time, which is very rare case.

You can restrict this by creating unique constraint on that field, but first you need to manually update the numbers (which are duplicate) and then enable unique. 

Mark the comment as a correct answer and helpful if it helps.

[Community Alums]

Hi Sukran,

We also faced this scenario in past.

Probable Reason for this to occur :

• Reason 1:
  The issue can occur from multiple pushes being made to the submit button. Although generally this is in conjunction with a network latency issue (i.e. where a push is sent and upon reconnection, another push is sent separately), it can simply occur without.
• Reason 2:
  One possibility is if there is a double insert caused by a business rule that contains a current.update or an .update when the record is inserted.
• Reason 3:
  One scenario is where you cloned over from production and production already have that number.

Solution :

As of now, unless there is a way to reproduce this issue, or if there is some type of pattern of the issue, it would be difficult to pin point what may cause the issue.

The best way to resolve this issue is:

• To impose the unique numbering on task table via a Business rule so that duplicate numbers will not be created. Before every update, it will make sure that a new number is assigned to the record.

OR

• Enable a unique index on the table.
  Note: While unique indexes ensure data integrity they also prevent any insert involving a duplicate number. This may cause unexpected errors during data entry.

A business rule (run on the server side) that checks for uniqueness on insert is probably the least intrusive option as making the task.number index unique at DB level might have other side effects.

Please Check Enforcing Unique Numbering in product documentation for more information.

https://docs.servicenow.com/bundle/jakarta-platform-administration/page/administer/field-administration/concept/c_EnforcingUniqueNumbering.html

Please mark this comment as Correct Answer if it helped you.

You can refer to this article as well.

https://community.servicenow.com/community?id=community_article&sys_id=b436c8e8db664850414eeeb5ca961975

Cheers,

Hardit Singh