How do you keep ServiceNow CI location fields trustworthy?
A ServiceNow CI's location field is a claim, not a fact — it records the last thing someone told the CMDB, whenever that was. Keeping it trustworthy takes three things: a location model granular enough to be useful, a defined owner for every update path, and ideally an automated feed that re-confirms location whenever a person actually touches the asset.
What granularity should the location model have?
ServiceNow's cmn_location table supports an arbitrary hierarchy, and the temptation is to either under-build it or over-build it. Under-building looks like one location record per building, sometimes per campus — technically correct, operationally useless. If Facilities gets a work order that says "infusion pump, Building C," nobody can act on that without walking every floor. A location model that stops above the room level isn't a location model; it's an address book.
Over-building has the opposite failure mode. Some CMDB owners try to model every location down to the shelf or the bed, on the theory that more granularity is strictly better. In practice, granularity below what your organization can realistically keep current just becomes another field nobody updates. A room-level record that gets touched every time an asset moves is worth more than a bed-level record that was accurate once, during data load, and has drifted ever since.
The right level is usually campus → building → floor → room, with room being the finest grain that a normal workflow — a move ticket, a work order, a presence check — can realistically refresh. Some environments justify a finer level for specific asset classes (imaging suites, server racks), but that should be a deliberate exception, not the default granularity for the whole hierarchy. Build the tree to match what your update mechanisms can actually sustain, not what would look complete in a diagram.
Where do location updates actually come from today?
In most ServiceNow instances, the location field gets touched through three paths, and each has a distinct failure mode worth naming separately.
| Update path | How it's supposed to work | How it actually fails |
|---|---|---|
| Move tickets | A formal ticket documents the move and updates the CI record as part of ticket closure. | Only covers moves that generate a ticket. Informal moves — someone grabs a spare workstation, a device gets handed off in a hallway — never touch the ticketing system at all. |
| Discovery | Automated network discovery periodically re-scans the environment and updates CI attributes. | Discovery sees network topology, not physical placement — a device can report the same subnet from three different rooms, or three different buildings on the same VLAN. It can update whether an asset exists and is reachable; it has no reliable way to know where the asset physically is. |
| Manual edits | A CMDB administrator or asset owner opens the CI record and corrects the location field directly. | Depends entirely on someone noticing the record is wrong and taking the extra step to fix it, with no built-in trigger and no urgency — so it happens rarely, and disproportionately for high-visibility assets rather than the long tail of ordinary equipment. |
None of these three is wrong to use. The problem is relying on any one of them alone, or assuming that having all three configured means location is being maintained. Each covers a slice of the update surface; the gaps between them are where drift accumulates. For a broader look at why that gap widens over time regardless of which paths are configured, see our breakdown of CMDB location drift.
Why doesn't Discovery solve location?
This is worth stating plainly because it's a common assumption among teams that haven't run into the failure mode yet: network-based discovery tools are excellent at telling you an asset exists, is reachable, and is configured a certain way. They are not designed to tell you where an asset physically sits, and treating them as a location source produces confident, wrong answers rather than honest gaps.
The mechanism is straightforward. Discovery infers presence from network behavior — which switch port, which subnet, which access point a device associates with. A laptop that roams from a third-floor office to a conference room on the first floor to a colleague's desk in another wing can report the exact same subnet the entire time, if those areas share VLAN configuration, which is common in flat or lightly segmented networks. From Discovery's point of view, nothing happened. From a facilities or compliance point of view, the asset moved three times.
The inverse failure also happens: an asset can change its apparent network location — a different access point, a different switch — without physically moving at all, simply because of roaming behavior or network reconfiguration. Either direction produces a location field that looks maintained (it has a recent-looking value) while carrying no actual information about physical placement. Discovery is a genuinely valuable input for existence and configuration accuracy. It is not a substitute for a location-specific update mechanism, and treating it as one is one of the more common ways a CMDB ends up confidently wrong.
What does good update discipline look like?
The organizations that keep location fields honest tend to share a specific pattern: they don't ask staff to perform a separate location-update step. They bundle the location change into a workflow the person is already completing for an unrelated reason — closing a move ticket, finishing a preventive maintenance inspection (PMI), completing a work order. If updating location requires opening a second screen and doing extra work that has no immediate payoff for the person doing it, it will be skipped under time pressure, and time pressure is the normal operating condition for most field and facilities staff.
The second piece is a verified-timestamp field sitting next to the location field itself — not just "current location" but "when was this last confirmed, and by whom." A location value with no freshness indicator is indistinguishable from a value that's five years old. Once that timestamp exists, it becomes possible to build the third piece: a periodic exception report surfacing CIs whose location hasn't been confirmed in some defined window — 90 days, 180 days, whatever matches your asset turnover — so that stale records get flagged for attention instead of sitting silently in the database looking exactly as authoritative as a record confirmed yesterday.
None of this requires new infrastructure. It requires deciding where in your existing ServiceNow workflows a location confirmation naturally belongs, adding the timestamp field if it isn't already there, and building one report that nobody currently has. The hard part isn't technical; it's making the update the path of least resistance instead of an extra chore.
What does an automated confirmation feed look like?
The pattern above still depends on a human remembering to update ServiceNow directly, which means it inherits the same fragility as manual editing — just with better habits layered on top. A more durable version pushes the update from outside the platform: an external system that records verified physical presence — because a technician was standing in front of the asset doing something else entirely — writes three fields back to the CI whenever that happens: current location, a last-verified timestamp, and the identity of whoever verified it.
The integration pattern for this in ServiceNow is well established: a Scripted REST API endpoint accepts the incoming payload and maps it onto the CI record's location and verification fields. This keeps ServiceNow as the system of record — nothing about the CMDB's authority changes — while making the location field self-healing in the specific sense that it gets re-confirmed as a side effect of ordinary work rather than requiring a dedicated update task that competes with everything else on someone's plate. It's the same idea as the update-discipline pattern above, just moved outside the platform and made automatic instead of dependent on someone remembering. If you want the deeper argument for why attaching updates to existing work beats both manual discipline and full real-time tracking infrastructure, that's covered in our piece on CMDB drift.
Where Forager fits
Forager is one implementation of the automated confirmation feed described above. When a technician confirms an asset's presence during normal work — closing a ticket, completing a PMI, walking a floor — that confirmation can push directly to ServiceNow via the Scripted REST API pattern, updating the CI's location, verification timestamp, and verifying technician in the same motion. Setup takes under an hour, per the public FAQ, using a Scripted REST API guide rather than middleware or batch jobs.
The integration is entirely optional and toggleable — Forager's floor plan visualization, presence confirmation, and attestation log all work independently of any ServiceNow connection, and the webhook can be switched off at any time without losing attestation history. When it's on, ServiceNow stays the system of record; Forager just gives it a steady stream of verified-physical-presence events instead of relying on move tickets and manual edits to carry that load alone.
For teams already running ServiceNow as their CMDB, this is usually the cheapest way to close the location-freshness gap without standing up continuous RTLS infrastructure. See how Forager works, or read the integration details at docs.harbinge.rs.
See asset intelligence on your own floor plan
Forager confirms asset locations as a side effect of the work your techs already do — $15/device/yr, no infrastructure changes. How Forager works or talk to us.