Business Rule(Create CI on insert) Blocking Import Despite No Duplicate CI Found
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-26-2025 08:11 AM
One of the business rules (Create CI on insert) is preventing data from being imported into our alm_hardware table.
As per my understanding, it is meant to stop duplicate CIs.
However, when I manually check, I don’t see any existing records matching the data I’m trying to import.
Thank,
Faruqui
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-26-2025 09:47 AM
Hello,
My first thought is that you may have a mandatory field on the related CI class and you have that at the dictionary level instead of being done at the client level. The BR will most likely not like to create a CI from the asset with the missing mandatory field. This is why it can be better to avoid setting mandatory fields at the dictionary level for CI records because of importing data in multiple ways (my opinion). The other thing might be the model being used on the asset side it not aligned or setup properly with regards to the CI class. I would make sure the data is valid as well. Remeber, there is a sync that occurs since they are two different records but tied together especially based upon the model cat in the model.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-26-2025 02:21 PM
For Assets, the Model and Model Category fields are the alfa omega of the whole process, are these two properly populated?
Also, Assets are often linked to a parallel CMDB record (not always but very often), check whether it is not blocked by already existing CMDB when creating a new Asset. Or any other issue in the CMDB tables.
/* If my response wasn’t a total disaster ↙️ ⭐ drop a Kudos or Accept as Solution ✅ ↘️ Cheers! */
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-26-2025 09:51 PM
Thanks everyone for the helpful insights!
I found that the issue was due to the serial number already existing in the cmdb_ci_computer table. Once I removed that record, I was able to import the data into the alm_hardware table successfully without the Business Rule being triggered.
However, I’m a bit confused about the expected behavior here. I’m new to this project, but logically, if a serial number already exists in the cmdb_ci_computer table, shouldn't the import just update the existing CI instead of blocking the import? Or is that something we need to explicitly configure?
Currently, I’m importing data using the Product Model and alm_hardware tables with the required logic. For new entries, the related record in cmdb_ci_computer is being created successfully. But for existing ones, it fails unless I manually remove the CI.
My question:
Do we also need to include the cmdb_ci_computer table in the transform map logic to handle updates when the CI already exists? Or is there a better approach to manage this kind of situation?
Thanks again for your support!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-26-2025 11:19 PM
@ahmadfaruqu,
I was thinking that, because:
The alm_hardware table has a one-to-one relationship with cmdb_ci_computer.
When you create an alm_hardware record, a corresponding cmdb_ci_computer CI is auto-generated (via Business Rules like Create Asset CI Relationship).
If a CI with the same serial number already exists, the system will try to insert a duplicate and it was the blocker for oyur Business rule
How do you import the records, classic method with a transform map? Perhaps you can set the colaesce evaluation on the serial number field.
Coalesce is a "check" that if a record with the same value:
- If it already exists, it will get updated,
- If it doesn't exist, it will create a new record.
But I would be very careful with this, as it might be case sensitive or if it is copied with a blank space, it can cause you polluting the CMDB/Asset tables with messy data.
/* If my response wasn’t a total disaster ↙️ ⭐ drop a Kudos or Accept as Solution ✅ ↘️ Cheers! */