Is there a reason the Asset form does not prevent creation of duplicate asset records having the same Serial Number?

[WB]

Our warehouse team receives hardware assets (PCs, Monitors, Servers, etc.) and manually enters the new device into ServiceNow.  Occasionally, the same asset and it's serial number are entered twice and we have a duplicate asset record. Out of Box the Asset Form doesn't prevent creation of an asset with an existing Serial Number.    

Does anyone know if there is a legitimate Asset Management use case or reason to explain why the Asset Form doesn't prevent the manual creation of a duplicate assets with the same Serial Number? 

Thank you.    

[Community Alums]

Hi,

It is no validation as Serial Numbers might be same from different vendors. Although, it is very unlikely but Servicenow doesn't provide it OOB. For our previous clients we have put this as a custom validation. If by any chance any Serial number comes same in future , they can raise a ticket with ServiceNow Admin to update Serial Number from the backend.

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

Cheers,

Hardit Singh

Connect with me on YouTube

[shloke04 · Accepted solution]

Hi @WB 

Setting the Serial Number field of the CMDB or Asset tables may seem a good idea for preventing Duplicate CIs and Assets, but it really isn't. These are some of the reasons why this is not unique by design, and should stay that way:

• Serial Numbers are not unique. There is no central world organisation like ISO for issuing blocks of serial numbers. There is for network MAC addresses and public IP addresses, making those good for unique identification, but there isn't for Serial Numbers.
• Several components within the same system may share the same serial number, or at least report the same serial number when queried via the management interface. For example Stacked Switches, Storage enclosures, Blade Chassis, cloned Virtual Machines and others.
• Setting a Unique constraint in the Dictionary applies at the SQL Database level, not the form or application level. This means an insert or update attempting to set a serial number that already exists in another record will cause a database Exception, crashing the transaction at that point, with no chance of handling the error in a safe way. The error you will see in the system log will look a lot like:
  

  FAILED TRYING TO EXECUTE ON CONNECTION xx: INSERT INTO cmdb (,...,`serial_number`,...) VALUES(...,'123456',...),INSERT INTO cmdb$par1 (...) VALUES(...)
  java.sql.BatchUpdateException: Duplicate entry '123456' for key 'serial_number'

• If duplicate values already exist when Unique is first set, you will get Data Loss. At the point that the Unique checkbox is set, the SQL database builds a unique index for the field. Any records that don't fit that new constraint are deleted so that the SQL data is consistent with the column/index settings. If the unique field is only defined on one partition of the CMDB, then only part of the record will be deleted, leaving an orphan sys_id in the other table partition, corrupting the whole CMDB.
• The Serial Number field for the main CI is not the primary field for identification, because a CI can have several different Serial Numbers, in the same way that the device may have several IP addresses. We use the cmdb_serial_number table for storing all those different serial numbers by type, and often they are the same. For example the System Serial Number may be the same as the BIOS Serial Number. Where 2 CIs correctly have the same serial number in the main CIs Serial Number field, we don't generally have a problem because the separate Serial Number table records for the devices will contain different ones for unique identification.
• Out-of-box code expects to be able to create CIs with serial numbers the same as other CIs. That is the design of the features, and setting serial number as unique will break that functionality. For example Discovery Sensor code may continue running thinking it has successfully inserted a record, and use the sys_id it thought it had created in reference fields in other records that do get created, breaking things like  relationships with other CIs and Service Maps.
• The correct use of the Identification and Reconciliation rules and APIs will accomplish the same goal. During inserts and updates through that API, duplicate CIs are detected and the appropriate action taken automatically. Where existing CIs appear to be the same, based on several identification fields, de-duplication tasks are created, and Duplicate CIs can be reported on in the CMDB Health Dashboard. Preventing duplicates by the correct identification of existing records during inserts and updates is the main purpose of the feature.

Most of these points also apply to other fields in the CMDB, such as as Name, Asset Tag, Correlation ID, etc.

Also to note from Paris, there is a property through which you can make Serial Number as Mandatory as well. By default the property is set as False. You can make it as True and should make the Serial Number as Mandatory as you need. Please refer to below HI article for more info on this:

In upgraded instance the field does not show up as mandatory.
-> Making serial number mandatory is new feature introduced in 'Paris', which will be turned off by default for upgrading customers.
This feature is controlled by a system property "glide.asset.create_ci_with_ire".
Release notes - https://docs.servicenow.com/csh?topicname=c_ManagingAssets.html&version=latest

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0862319

Hope this helps. Please mark the answer as correct/helpful based on impact.

Regards,
Shloke

[WB]

Fantastic, detailed answer!  Exactly what I needed to pass on to the development team so they are aware of best practices and the not so obvious risks.  Sorry for the delay in marking this correct.  

[Scott Halverso1]

I've often longed for a feature like this at the UI layer, when a user is creating a new asset/ci manually. 

Feedback to the user that says we've detected you may be creating a duplicate with information in a quick view into the potential duplicate(s).  Would you like to proceed?

I'd be looking for ways to change the receiving process to prevent accidents.  Using scanners is often a frequent first step.