Tracking Racks in ServiceNow as CIs and Creating Relationships with other CI Classes

[JeffShaffer]

In ServiceNow is it preferable to manage Racks (including Room, Row and Rack Unit info) as Configuration Items (there is a Class named "Rack") or as attributes on other CIs (switches, routers, servers, etc.)? We want to begin managing our Rooms/Rows/Racks/Rack Units as CIs and correlate the RUs back to the specific devices populating those RUs. What is the recommended approach to doing this?

[Matthew_13]

Hi Buddy,

In most cases, the recommended approach in ServiceNow is to treat racks as Configuration Items, not just as attributes on other CIs. ServiceNow already provides a Rack class for this reason, and it works well as a physical “container” for devices.

A common way look like this:

• Rooms are usually handled as part of the Location hierarchy (site → building → room). They don’t always need to be full CIs unless you have a strong use case.

• Rows are often kept as a simple attribute or naming convention, unless you need to manage them independently.

• Racks are created as Rack CIs.

• Devices (servers, switches, routers) are related to racks using a standard CMDB relationship for example, “Rack contains Device”

For rack units (RUs), the most scalable approach is to store RU position on the device CI not as separate RU CIs. Typically this means adding fields like “RU start” and “RU height” or RU end on the device. This lets you see where each device sits in the rack and calculate rack usage without creating dozens of extra records per rack.

Creating individual RU records as CIs is usually only worth it if you need very detailed data center management, such as slot reservations, move/add/change workflows at the RU level, or detailed capacity and lifecycle tracking. For most CMDB and ITSM use cases, that level of detail adds complexity without much benefit.

So, Basically: use Rack as a CI, relate devices to it, and track RU placement as attributes on the devices. That gives you good structure, clean reporting, and avoids over-modeling unless you truly need DCIM-level detail.

@JeffShaffer - Please mark Accepted Solution and Thumbs Up if you found helpful!

[JeffShaffer]

Thanks Matthew_13 Mega Sage, we appreciate it, and will give it a go!

[Matthew_13]

@JeffShaffer  Hello buddy thank you for the helpful; if answered please mark Accepted solution as well. Thanks Kindly