Why Is There No SSID (WIFI)Class in ServiceNow?

[Georgi2]

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?

[Ben Schlick]

Great question. ServiceNow is not a premier monitoring tool, especially for network devices, so there's no wonder why they wouldn't have anything that specifically references this.

Long story short, it is good for the goose and the gander. SSID/wlan's should have a relationship to the switch/router -> controller -> APs (vlan optional, assumed 1 if not defined) that also references a metrics table from your 3rd party application of choice.

Even if this was fixed, it wouldn't solve your problem of "Accurate CI identification for incident routing". It's not always the access point, wireless controller, switch/router that are the problem, sometimes its the end-users device(s). Ideally, synthetic user monitoring would constantly troubleshoot these issues from a network perspective and report directly into servicenow's itsm stream.

synthetic user monitoring = remote laptop with 3rd party network software installed that constantly checks network connection, application reliability, and system configuration changes. The software would report to both, centralized monitoring dashboard AND servicenow. This essentially negates the need for tracking ssid/wlan because it would be reported in XformatX into your ticketing system, always with the correct ci identified, user or otherwise.  

You can see an example of this from solarwinds End-User experience monitoring.

The problem with using vendor specific is that their vendor specific. As a monitoring professional, I'd recommend a centralized network monitoring tool that provides 85-95% functionality of each vendor into one product and utilize that tool for the integration into servicenow. More tools are not more efficient. Network engineers do NOT purchase and implement their software with an enterprise integration as a requirement which is a failure in strategy and architecture. 

ssid/wlan are retrievable via snmp, servicenow CAN see them with discovery so this is a design gap.

https://www.solarwinds.com/network-performance-monitor/use-cases/wifi-analyzer

the integration from 3rd party monitoring tool(s) is NOT regulated, meaning no one has said what the best practices are for integrations. Yes, event management allows the ingestion of "events" from any outside source only to be correlated using servicenow. THIS IS NOT BEST PRACTICE. Rather monitoring tools should correlate/manage events and alerts natively (Syslog RFC3164 0-7 severity level, only when the alert transitions to an "incident" should the message ever be sent to servicenow as an incident and nothing else.)

snmp+syslogs (different protocols used together) 

[Georgi2]

Appreciate the detailed response, and I agree with most of your monitoring architecture points. Correlation belongs upstream in a centralized NPM tool, only incident-grade events should cross into ServiceNow, synthetic monitoring catches endpoint-side failures that no infrastructure CI can explain. All correct.

But the question isn't about monitoring. It's about configuration management.

A CI does not need to generate telemetry to belong in the CMDB. We model service offerings, business capabilities, software entitlements, contracts. None of those produce SNMP traps. Configuration data exists to answer "what is this, where does it live, what depends on it, who owns it, what is its intended state." That is a separate concern from "is it currently healthy." If it is important enough to be managed, it should be in the CMDB.

A few specific points:

On synthetic monitoring solving routing: The synthetic probe that fails to associate with SSID at site US0001 still needs a target to report against. If the SSID is not a CI, that event lands on the AP or controller, which is the exact routing problem the post opens with. Synthetic monitoring produces the signal. The CMDB provides the anchor. Both are needed.

On your own relationship model: You wrote that "SSID/WLANs should have a relationship to the switch/router -> controller -> APs." That is a CMDB relationship model, and it requires the SSID to exist as a CI. You cannot have a meaningful relationship between something that exists in the CMDB and something that does not.

On "ServiceNow CAN see them with discovery so this is a design gap": This is the strongest line in your reply and I agree with it completely. The data is available via SNMP, vendor APIs, and Discovery patterns. The gap is purely on the data model side. What class do I put this under and the reason for my post? All suggestions say, extend existing classes. My argument is, why is this not an OOTB Class already, while seemingly everything else is.

On the use cases beyond incident routing: Change Enablement, Security and Compliance posture, and CSDM service dependency mapping are not monitoring problems. They are configuration management problems that no NPM tool, synthetic or otherwise, solves. Those are the use cases that prove the SSID belongs in the CMDB regardless of what is happening at the monitoring layer.

The TL;DR: monitoring and configuration management are complementary, not substitutes. A great NPM stack still needs a CMDB that knows the broadcast entity exists.

[Ben Schlick]

I'm not dismissing the need for ssid to be configuration item. I thought I made it clear in the paragraph:
"Long story short, it is good for the goose and the gander. SSID/wlan's should have a relationship to the switch/router -> controller -> APs (vlan optional, assumed 1 if not defined) that also references a metrics table from your 3rd party application of choice."

Turns out, configuration management and monitoring are no different. I do not expect you to come to this conclusion in the next 5 minutes, or even the next 5 months. Did you know that SNMP can also pull attributes like location, business unit, service, service offering? All of which can be configured on the DEVICE BEFORE IT HITS THE NETWORK which essentially negates/extends the need for a CMDB; many people/organizations do not understand this! The problem is, who configures these attributes and what attributes should they be? Precisely where the CMDB comes into play. I have personally built this in the monitoring tools we've discussed.

An organization purchases ServiceNow for it's enterprise "capability" but have NO IDEA what it takes to make it an enterprise application. It starts with the CMDB/CSDM which provides a foundational data model used to correlate data. Tables like Company->business unit->department are/should correspond to Location (cmn_location->cmn_building->cmn_floor->cmn_room (not sure if floor or room are correct, i haven't seen what tables wsd or other remote work apps use but they are similar.) If these data structures are not accurate, or the network team has to make their own up, you'll NEVER have a complete ITSM picture let alone enterprise ServiceNow implementation.

Again, the best solution for this use-case is for servicenow to solve by adding more tables/relationships. This is what I'm saying in reference to "what's good for the goose is good for the gander".

Although servicenow started with ITSM doesn't make it the most important application in the ServiceNow ecosystem; Data foundations is.

I'm not sure what you mean by "The TL;DR: monitoring and configuration management are complementary, not substitutes. A great NPM stack still needs a CMDB that knows the broadcast entity exists." How is monitoring different than a cmdb? If you don't have monitoring, do you have a cmdb? Are import sets a form of "monitoring"? A monitoring tool doesn't need to know anything about the CMDB; It only needs access, subnet to scan, and device/app credentials.

The term "cmdb" is arbitrary on where it exists. Just because ServiceNow has an application called "cmdb" does NOT mean it is the most up-to-date cmdb in the organization; often times this falls to the enterprise monitoring tool with the most accurate data. ServiceNow people just say; "we can just import all of your data and call our cmdb good"... What a joke.

side note: I do not put too much weight in the data foundations cert. there's too much missing about databases and too much about servicenow lingo.

[Ben Schlick]

I'm not dismissing the need for ssid to be configuration item. I thought I made it clear in the paragraph:
"Long story short, it is good for the goose and the gander. SSID/wlan's should have a relationship to the switch/router -> controller -> APs (vlan optional, assumed 1 if not defined) that also references a metrics table from your 3rd party application of choice."

Turns out, configuration management and monitoring are no different. I do not expect you to come to this conclusion in the next 5 minutes, or even the next 5 months. Did you know that SNMP can also pull attributes like location, business unit, service, service offering? All of which can be configured on the DEVICE BEFORE IT HITS THE NETWORK which essentially negates/extends the need for a CMDB; many people/organizations do not understand this! The problem is, who configures these attributes and what attributes should they be? Precisely where the CMDB comes into play. I have personally built this in the monitoring tools we've discussed.

An organization purchases ServiceNow for it's enterprise "capability" but have NO IDEA what it takes to make it an enterprise application. It starts with the CMDB/CSDM which provides a foundational data model used to correlate data. Tables like Company->business unit->department are/should correspond to Location (cmn_location->cmn_building->cmn_floor->cmn_room (not sure if floor or room are correct, i haven't seen what tables wsd or other remote work apps use but they are similar.) If these data structures are not accurate, or the network team has to make their own up, you'll NEVER have a complete ITSM picture let alone enterprise ServiceNow implementation.

Again, the best solution for this use-case is for servicenow to solve by adding more tables/relationships. This is what I'm saying in reference to "what's good for the goose is good for the gander".

Although servicenow started with ITSM doesn't make it the most important application in the ServiceNow ecosystem; Data foundations is.

I'm not sure what you mean by "The TL;DR: monitoring and configuration management are complementary, not substitutes. A great NPM stack still needs a CMDB that knows the broadcast entity exists." How is monitoring different than a cmdb? If you don't have monitoring, do you have a cmdb? Are import sets a form of "monitoring"? A monitoring tool doesn't need to know anything about the CMDB; It only needs access, subnet to scan, and device/app credentials.

The term "cmdb" is arbitrary on where it exists. Just because ServiceNow has an application called "cmdb" does NOT mean it is the most up-to-date cmdb in the organization; often times this falls to the enterprise monitoring tool with the most accurate data. ServiceNow people just say; "we can just import all of your data and call our cmdb good"... What a joke.

side note: I do not put too much weight in the data foundations cert. there's too much missing about databases and too much about servicenow lingo.