Why Is There No SSID (WIFI)Class in ServiceNow?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 hours ago
I have been researching this for a long time, and it is genuinely puzzling why the OOTB CMDB has no concept of a Wireless SSID. Not even as a standard field or reference point. No Plugins either have this. There are some Radio classes but they are for long range. It is a real construct that we all use, and network administrators spend half of their time troubleshooting it.
If you log into Aruba Central, Meraki, UniFi, or any wireless vendor dashboard, SSIDs are first class objects. When you check network health, the SSID is a primary metric you monitor. If a user reports that the Wi-Fi is down, a network tech immediately thinks: Which SSID? Which APs broadcast it? What is the encryption type? Has a certificate expired? Is it WPA2 or WPA3? What VLAN is it bound to?
But in the ServiceNow CMDB:
- There is no SSID class. We have cmdb_ci_wap_network for access points and cmdb_ci_wireless_lan_controller for controllers, but nothing for the logical network users actually connect to.
- There are no fields to represent SSID attributes. Signal strength, encryption, band, or VLAN binding have nowhere to live.
- There is no relationship to other CIs. You cannot accurately correlate an incident to an SSID because the SSID does not exist as a Configuration Item.
Look at the Incident routing problem. A user reports the Wi-Fi is down. What CI do you select on the ticket?
- A single AP? Incorrect, because the SSID broadcasts from many APs simultaneously.
- The WLC? Also incorrect. The controller might be up, but the specific SSID configuration or authentication is the problem.
- The router or switch? Not really. The underlying network is fine, it is just the wireless broadcast that failed.
We end up logging incidents against the wrong target. Impact analysis breaks down, and correlation engines have nothing to anchor on. The CMDB treats wireless as a black box, even though every network team treats it as a critical, managed asset with its own operational lifecycle. We cannot track where an SSID is broadcast or what APs have it. Yet any source of wireless discovery data like Aruba, Meraki, UniFi, or Cisco DNAC has this information readily available. And no, just mapping it as a high level Service is not a complete solution. It is a logical infrastructure component.
The real question is why this isn't out of the box.
Any community research or suggestion I find usually points to the same workaround: extend a class and create custom manual fields. Is that really the accepted solution? We have OOTB classes for incredibly obscure hardware and logical components, but a fundamental concept like an SSID has nothing. We have cmdb_ci_service_consumer, cmdb_ci_hardware, cmdb_ci_network_adapter, cmdb_ci_storage_device, and dozens more. We can model every layer of infrastructure, but the actual broadcast entity that users connect to every single day does not exist as a managed object. That is not just a gap. That is a design blind spot.
Has anyone else solved this elegantly without heavy customization, or is extending the class the only real way forward?
