CMDB OTB tables vs. Custom Tables

[Vicki H]

All our Configuration Items were loaded into two custom tables. We have routers, switches, and other devices loaded into the custom tables rather than the Out of the Box locations provided by ServiceNow.  What functionality is lost by not using the OTB CMDB table?   Is it worth mapping the equipment to the OTB locations in ServiceNow?  In systems past, we have found out that by going customer, we break build in system tools.  Thanks in advance.

[Vicki H]

u_icn_cis and u_icn_circuit_cis

Currently I can see Incident history on the CI's Incident related list if that CI was selected as the Incident CI.  We need to add those tabs on the form, but the data is there.   

[Sanjay Bagri1 · Accepted solution]

Hi, The main difference is between cmdb and custum table . Cmdb configuration management database means all kind of assets and ci relationship will manage by cmdb . If you need to make the any relationship then thare lot of approach will require so snow has given to us easy way to work . And custum table is created as par customers requirements. But what ever cmdb has that is the basic table which requires in every organization. For that purpose they have given option for us . If it is helpful for you. Please Remember it mark it as correct and also helpful. Thanks Sanjay Bagri Dxsherpa.com

[Vicki H]

In looking further into this issue, it appears that the two equipment tables were add as CI Classes.  So in essence the all my equipment, switches, routers, etc.. are all lump together under the same class .  I am not familiar enough with the CMDB out of the box features so I don't know what we lost by loading the CIs this way.  I feel that we surely have lost built in features of the SN product, but am struggling to quantify them in a way that will help me justify getting them loaded correctly.  The obvious answer would be that there are OTB fields (not on the form) that are already developed to hold information.  We are loading the CIs from other databases, so re-mapping them would be work, but not impossible.  We are not using discovery.   So I looked at the Class Manager and it becomes apparent to me that by shoving all the CIs under a customer table we are making all our CIs generic.  If we use the out of the box CI Classes we can add the attributes we need for each class specifically to each class.  If we lump them together than we have to either be very generic on attributes or put all attributes of which many will not apply to most of the CI devices - All because they are the same CI Class.  Then I see that we can set Reconciliation and Identification rules by class.  Again this would point to breaking out classes.  then there the other potential development points of Suggested Relationships, and the Health of the class.   Are there any other areas out there that would also be a good point to add about breaking out the CIs into their correct classes?  Thank you for all your help in pointing me in the right direction.