Parent column of the cmdb_ci_service table points to different tables in 2 different instances.

[HugoFirst]

While looking to load data into the CSDM tables, I ran into an issue with the parent field in the Service table ( cmdb_ci_service ).  

In my personal development instance, where I did much of my preliminary research, the parent field of this Services table points to itself ( cmdb_ci_service ).   This is what I expect.

However, when I started working in my Dev instance, the parent field of cmdb_ci_service points to the service_offering table.  This complicates things greatly.

The build tag on both instances is the same: glide-yokohama-12-18-2024__patch6-07-17-2025

Has anyone seen this kind fo discrepancy before?  This is the first time for me.

[Swapna Abburi]

Hi @HugoFirst 

How are you importing data? If you are using transform maps, then it could be that CI with same name present in both the classes (service and offerings). 

[HugoFirst]

I am not importing data.  I have a fix script that takes data from a couple of existing tables to fabricate records for Business Services and Technical Managment Services.  Each Technical Management Service should have a parent Business Service.   But that is not possible if the parent field for the cmdb_ci_service table points to service_offering.

[Rafael P]

Hello @HugoFirst ,
It looks like the difference is due to instance-specific configuration. You should first check the dictionary entry for cmdb_ci_service.parent in your Dev instance to see whether it points to service_offering or cmdb_ci_service. Based on that, adjust your data load logic: if it points to service_offering, link services to service offerings; if it points to cmdb_ci_service, maintain hierarchical service relationships. If you want consistency with your personal instance, you could update the dictionary to point back to cmdb_ci_service, but be careful as this might affect existing relationships and applications. Test your import with a small batch first to ensure the parent relationships are created correctly according to the instance configuration.

[HugoFirst · Accepted solution]

Just wanted to reply to put some closure to this post. Pertinent fact:  We implemented ServiceNow a long time ago, 2010.   When I viewed the parent field in the cmdb_ci_service table it pointed to the service_offering table.  This is a "child" table to cmdb_ci_service.  IN looking at the history of this field, that value was set in the original implementation, back in 2010.

I was able to update the Reference to this field to point to itself ( cmdb_ci_service ).  This is in alignment with the newer instances of ServiceNow.   All is now right with the world.