CMDB

[Mariana Elena G]

Hello, I'm building my company CMDB we are populating the Network and Cloud layer with graphconnectors because of we have monitoring tools that can start bringing information into the CMDB meanwhile we enable Discovery. 

However for Cloud layer we have 5 fields that our monitoring tool brings but in our transformation map but in ServiceNow there's no field that really fits for that information. So I have 2 solutions in mind but I have some concerns about them.

1. Add them as new fields, but here my concern is that I don't want to custom the cmdb, we are trying to do everything out of the box and avoid customizing for the implications it might has.

2. Re tag the name of some of the existing fields to add the information. But I really don't understando which implications or risk does it can have.

If anyone please help me with your feedback will be really much appretiate it, Because I'm stuck in the best decision to make

[Ashok Sasidhara · Accepted solution]

Create new fields if there is actually any use case for tracking those attributes. Avoid populating those attributes if they don't support any business objective. We should keep only relevant CI classes and attributes in the CMDB.

Make sure to create any new attributes at the right level. i.e. If a new attribute is to be used in multiple CI classes, then it is better to create it at the parent level. If it is used for a specific CI class, create it on that specific class only.

Also ensure that the CMDB CI Class Models plugin is updated to the latest version. After updating this, you can check whether new CI classes with more suitable attributes have become available OOB.

[SteveMacWWT]

Your concern about upgrades is a good thing and should guide you as you grow usage of the CMDB. That being said, I agree with @Ashok Sasidhara stated. Sometimes the best option is to add new fields. 

A couple of notes I would add:

• More important than not creating new fields when they are not necessary, is the approach of not reusing existing fields just because they seem close to what you are trying to track. While this may seem safer than creating new fields, there is a better chance that it could create issues in the future. ServiceNow may be using that field already in OOB reporting, or as a trigger for something else. Or you could find later that you need that field for its intended purpose. 
• Not only should you check the latest version of the class models before making your customizations, but you should track updates to the class models to see if your custom field is added later added as an OOB field. While it may seem like it is okay to stick with your custom field because it is a minor difference from OOB, multiple years of that will come back to haunt you later. I can say from experience that this becomes difficult to unravel, and you end up with customizations you need to manage when SN will take care of for you. 

All that is to say: Keep future @Mariana Elena G in mind and don't cause them more pain in the future. You'll thank past Mariana for thinking of you.