How to remove "Invalid Insert" message on alm_hardware table?

[User5]

Hello,

We have a requirement to remove "Invalid Insert" message when  a record is being inserted  on alm_hardware table, i.e., currently if we duplicate an asset tag or an asset serial number that is in another asset record ServiceNow throws an "invalid insert" error when attempting to submit or edit an asset record.

When either one of these fields (asset tag or serial number) is matching ,i.e., is in another asset record the record should get inserted/created. Currently, its giving an invalid insert error message.

please refer to the screenshot below.

Thanks in advance.

[Oscar D · Accepted solution]

Creating an asset with the same serial number in ServiceNow is usually not recommended because it can cause complications. The AssetCISync mechanism, which is a ServiceNow function that synchronizes Configuration Item (CI) data and asset data, plays a role in avoiding such scenarios. This mechanism performs checks according to your Identification and Reconciliation (IRE) rules to detect duplicate CIs before creating a new asset. When AssetCISync identifies an existing CI with the same serial number as the new asset being added, it cancels the update to prevent duplication.

This safeguard is particularly vital when using ServiceNow's Discovery module. Discovery aims to match CIs based on their serial numbers. If you have multiple CIs with the same serial number, these will generally be considered duplicates, potentially causing inaccuracies in your Configuration Management Database (CMDB) and negatively impacting asset tracking and management.

However, ServiceNow provides a workaround for bypassing the IRE duplicate validation via a system property: glide.asset.create_ci_with_ire. When set to false, this property will enable the creation of new assets without checking for duplicate CIs. While this can solve the immediate issue, it's important to approach this method with caution. Bypassing IRE's duplicate validation may create downstream impacts that are not immediately noticeable.

For instance, this could lead to an inflated CMDB with duplicate entries that can cause confusion and inaccuracy in asset management and reporting. It could also compromise the effectiveness of processes and workflows that rely on accurate CI and asset data, such as Incident Management, Change Management, and IT Service Management processes. Therefore, it's crucial to consider the potential implications thoroughly before opting to change this setting.