Can you change the Hierarchy of CMDB Classes after they've already been created?

Colin Wilson · ‎03-14-2023

Imagine a class structure as follows:

Config Item [cmdb_ci]
- Facility Hardware [cmdb_ci_facility_hardware]
  - Furniture [u_cmdb_ci_facility_furniture]
    - Desk [u_cmdb_ci_facility_desk]
    - Table [u_cmdb_ci_facility_table]
    - Chair [u_cmdb_ci_facility_chair]
  - Lectern [u_cmdb_ci_lectern]
  - Podium [u_cmdb_ci_podiums]
  - HVAC [cmdb_ci_hvac]
- Hardware [cmdb_ci_hardware]

Is there an OOB way to move the Lectern / Podium classes so they are underneath the furniture class? The lectern/podium tables were created way before and without much thought as to an organizational hierarchy for furniture type stuff.

For argument's sake, assume that Facility Hardware and all extending classes have no (or the same) custom added attributes, identification rules, reconciliation rules, or suggested relationships.

CMDB Whisperer · ‎03-14-2023

There is (or at least used to be) several ways to do this, though this functionality has been decremented bit by bit over the last several years. At last check one method still worked (as of Orlando I think?), but only with custom classes. And even when doing so, the reparenting was not captured in an update set, nor could it be manually added to an update set, so you had to do the reparenting separately in each instance. And if there were any identically named fields in both class branches that were not inherited, this resulted in errors. So, if you want to do it, hold your breath, cross your fingers, shake well before using, some assembly required. Because of these I would not recommend doing this, even if it is still possible. Rather I would suggest a low impact data migration approach. Create a new class under the desired structure, and make sure it has all of the appropriate fields, and then simply reclassify the original CI to the new CI class. Tip: as long as the field name of the field is exactly the same as the source field, the data will be retained when you change the class name to the new CI class. Now your original CI will exist under a new table, but I believe it will retain the original sys_id value. The only thing you will lose is the audit history, as those records don't get updated to the new table name.

The opinions expressed here are the opinions of the author, and are not endorsed by ServiceNow or any other employer, company, or entity.

View solution in original post

Ashok Sasidhara · ‎03-15-2023

Are they already managed as assets in the alm_facility table? If not, the best practice is to ensure that they are populated in the alm_facility table and then use model categories like desk, table, chair etc. to differentiate them. Then the model field can be used to indicate the exact model name of the desks, tables, chairs etc. All of these are typically managed as assets and would be managed also as CIs only in rare scenarios. Only those items for which incidents or changes might be raised should be maintained as CIs in the CMDB (which should be synced with corresponding asset record). Also instead of using so many custom CI classes, it would be better to use only u_cmdb_ci_facility_furniture class and use some type attribute to differentiate desk, table, chair, lectern and podium. A separate custom class is necessary only if they are valid CIs which requires many new attributes that are specific for that.

Colin Wilson · ‎03-15-2023

they are not already managed as assets, however, i think the solution you are proposing is the right way to tackle this issue. Thanks for your feedback!