Troubleshooting ServiceNow Hardware Asset Management: A Practical Guide

Troubleshooting a hardware asset problem means working back from the symptom to the record, the workflow, the access rule or the report that causes it. This page helps an asset manager separate a data fault from a reporting fault before anything is changed.

Diagnostic Approach

Hardware Asset Management tracks the complete lifecycle of physical devices. Troubleshooting requires understanding data flow: from asset procurement through deployment, operation and retirement.

Most issues stem from data quality problems: assets not being recorded when purchased, asset movements not being tracked or decommissioned assets lingering in the system.

Asset Not Appearing in System

Symptom: A physical asset exists but has no record in Hardware Asset Management. When you search for the asset by serial number or device name, no record is found.

First check whether the asset has been discovered automatically. If asset discovery is enabled, new assets should be automatically added when they connect to the network. Navigate to Discovery in ServiceNow and verify discovery is active and has found the asset.

If discovery did not find the asset, check whether the asset is actually on the network: is it connected? Is it in the right network segment? Does it have the right operating system or device type to be discovered?

If the asset should exist but discovery has not found it, manually create a record. Navigate to the Hardware Asset Management module and create a new asset record with the asset details: serial number, model, asset tag and assigned user.

Asset Appears Duplicate

Symptom: Multiple records for the same physical asset. Asset searches return two or three records for what should be one device.

Root Cause: Discovery created a record automatically, then a record was manually created without checking for existing records. Or the same asset was imported twice from different systems.

First determine which record is authoritative by checking which has the most complete information and most recent activity. Navigate to the duplicate records and examine the data. The record with more complete history is usually the keeper.

Merge the records: copy any missing data from the duplicate into the authoritative record, then delete the duplicate. Document the merge in a comment on the record for audit purposes.

Asset Assigned to Wrong User

Symptom: Asset records show the asset assigned to a user who no longer works there or who never received the asset.

Root Cause: Asset assignment was not updated when the user moved, retired or left the organization. Or the asset was incorrectly assigned during procurement.

Navigate to the Hardware Asset Management module and search by the user name to see all assets assigned to that user. Review each record to confirm it is correct. Update assignment for assets that were incorrectly assigned. For retired users, reassign the asset to the current user or mark it for recapture if no one has it.

Asset Location Unknown

Symptom: Asset records do not have a location field populated, or location field shows incorrect information.

Root Cause: Asset location was not captured during procurement or deployment. Or asset moved but the system was not updated.

Navigate to the asset record and check the location field. If it is empty, ask the current asset holder where it is located and update the record. If location is wrong, verify the correct location with the asset holder.

Decommissioned Assets Still in System

Symptom: Asset records for devices that are no longer in use remain in the active asset list.

Root Cause: Assets were retired but not marked as decommissioned in the system. Or decommissioning process is not being followed.

Navigate to the asset record and change the status to Retired or Decommissioned. Verify the retirement date is correct. If the asset was recently decommissioned, update the date to today.

Verify that your decommissioning workflow is correct: assets should be marked decommissioned when they are removed from service, not months later. This helps prevent old assets from being counted in active inventory metrics.

Asset Audits Show High Discrepancy

Symptom: Physical asset count audit finds many assets not in the system or system records for assets that no longer exist.

Root Cause: Asset data has drifted from physical reality. This typically happens when assets move and system records are not updated, or when assets are decommissioned but records are not updated.

Conduct a full reconciliation: physically locate and verify all assets in a department or location, then update system records to match. This is labor-intensive but essential to restore data quality. Focus on high-value assets first.

Start from the layer where the symptom appears

Hardware problems that show up on a screen are often caused a layer away from where they are seen. A report that omits a laptop may be fine while the record is broken, or the record may be complete and the report filter is excluding its status. Before changing any data, decide which layer you are in: the device record itself, the workflow that should have changed it, the access rules that decide who can see it, or the report that summarizes it. The table below pairs the most common symptoms with the layer to inspect first and the check that separates the layers.

Diagnosing a report that disagrees with the floor

When a physical count and a report disagree, resist the urge to correct the report. A corrected report hides the cause, and the same gap reappears next cycle. Work through the disagreement on a small sample first, usually a small sample of devices from the affected class, and record for each one whether the record is right, the report is right, or both are wrong. A pattern usually appears within that sample. If every error is a device recorded at one site, look at the location reference. If every error is a device retired within the last few weeks, look at the timing of the status change against the report refresh.

1. Pick the affected class of device and write down the report total and the physical total in the same place.
2. Take a sample of devices that appear in one total but not the other, and open each record directly rather than through the report.
3. Classify each sampled record as correct in the record, wrong in the record, or correct in the record but filtered out by the report.
4. If most errors fall in the third class, fix the report view and add a note to its owner. If they fall in the second class, the cause sits in the data or in the process that changes the data.
5. Trace any data fault to the step that created it, whether that is an import, an intake form, a repair closure or a manual edit.
6. Re-run the same sample after the fix and record the result, so the next reviewer can see which checks ran.

When a workflow stops moving an asset

A workflow that stalls leaves an asset in a state nobody owns. A common cause is a task routed to a group that has no members, or to a person who has left and was never replaced. Another common cause is a condition that was written for one device class and quietly fails for another, such as a rule that expects a serial number on every item where some classes have none. Look at the activity on the affected record, identify the last task completed, and check who or what the next task is assigned to. If the assignment is empty or points to a departed user, the fix is an assignment change, not a rerun of the workflow, because rerunning can duplicate the earlier steps.

Knowing when to rebuild rather than repair

Repairing records one at a time is reasonable when a fault affects a handful of devices. It is the wrong approach when a bad import created hundreds of records with the same error, or when a transform map was changed and the earlier batch was never reprocessed. In those cases, identify the import batch, confirm which records came from it, and decide whether to correct them in bulk or to retire the batch and reload it from a corrected source. Bulk correction is faster but only safe when the correct value for each field can be derived from the source rather than guessed.

Questions to ask before escalating

Why does a device appear twice after a manual entry?

A manual entry is often created without searching first, while discovery or an import had already created a record for the same physical item under a different identifier. Search on serial number and asset tag together before creating any record, and make the intake form require the search step rather than leave it optional.

Is it safe to delete a suspicious record?

Not until its history has been checked. A record with assignments, repair activity or financial links carries history that other records may depend on. Retire or mark it as a duplicate with a reference to the survivor, so the trail remains readable for audit.

What evidence should an escalation include?

Include the record identifiers, the report name and filter, the workflow activity for the affected asset, the date the symptom was first seen and the sample results. An escalation with those items often resolves in one exchange. Without them, the first hour of any investigation is spent reconstructing the same facts.

How do we stop the same problems coming back?

Assign each recurring symptom to one owner and one check, and review the list each cycle. Many repeat problems come from intake steps that are optional, status values added locally without updating reports, or groups that lost their last member. Fixing those three areas often removes much of the recurrence.

The best practices guide for hardware asset management covers how automated discovery reduces manual entry, which is the source of several of these symptoms. The testing checklist covers the inventory, lifecycle and reporting tests that can confirm a fix before it is treated as closed.