Common ServiceNow Hardware Asset Management Mistakes and How to Avoid Them

Hardware asset management problems in ServiceNow usually trace back to seven process mistakes: an inaccurate inventory, missing lifecycle and depreciation data, devices not linked to users or services, poor integration with the wider asset lifecycle, no audit trail for changes, ignored warranty and support dates, and no regular audit.

Mistake: Incomplete or Inaccurate Hardware Inventory

Many organisations do not have an accurate hardware inventory. Devices are purchased and deployed but never recorded in the system. Devices are retired but the records are not updated. A device is listed as owned by a user who left the company months ago, so no one can find it.

The symptom: inventory counts do not match actual hardware. During an audit, you find equipment not in the system, or equipment in the system that does not exist. The root cause is usually a process gap: hardware is not registered when purchased, or decommissioning is not tracked. The fix: implement a purchasing workflow in ServiceNow where every hardware purchase creates a Hardware Asset record, assign an owner, track location, and require a decommissioning process to close the record.

Mistake: Missing Hardware Lifecycle and Depreciation Data

Hardware has a lifecycle: purchase, deployment, refresh, end of support, decommissioning. If you do not track these milestones, you cannot manage hardware costs or compliance. Depreciation is also important: a three-year-old laptop has a different value than a new one; accounting needs this for financial statements.

The symptom: you cannot report on how long hardware has been in use, whether it needs replacement, or how much it is worth. The root cause is missing lifecycle fields in the Hardware Asset record: purchase date, deployment date, expected life, end-of-support date, depreciation rate. The fix: add these fields to your Hardware Asset records and ensure they are populated when hardware is purchased and updated when lifecycle milestones occur.

Mistake: No Link Between Hardware and User or Service

Hardware supports users and services. A laptop is assigned to a user; if the user leaves the company, the laptop needs to be returned. A server supports an application; if the application is retired, the server becomes available for reuse or retirement. If you do not link hardware to users and services, you cannot answer these questions when changes occur.

The symptom: orphaned hardware—devices no longer assigned to anyone, or servers supporting applications that no longer exist. The root cause is that hardware records do not include user or service relationships. The fix: link each Hardware Asset to a user (for personal devices) or a service (for shared infrastructure). Update these relationships when hardware is reassigned.

Mistake: Poor Integration with IT Asset Lifecycle

Hardware is part of a larger asset lifecycle. Devices are requested (through a service catalog), purchased (through procurement), deployed (and assigned to users), maintained (tracked in IT Asset Management), and retired (decommissioned and possibly recycled). Each step has data that must flow into Hardware Asset Management.

The symptom: Hardware Asset records do not match service catalog orders, or purchase information is not reflected in asset records. The root cause is lack of integration between systems: orders are in one system, procurement in another, asset management in ServiceNow. The fix: integrate these systems so hardware data flows end-to-end. When hardware is ordered in the service catalog, create a Hardware Asset record in ServiceNow. When it is purchased, update the record with purchase details.

Mistake: No Audit Trail for Hardware Changes

When a device is moved to a new user or location, that change should be tracked with a business justification. Why was this device moved? Who approved the move? Without an audit trail, you cannot track accountability. Additionally, when hardware is missing or stolen, you cannot determine when it went missing or who last had it.

The symptom: changes to hardware ownership or location are made without documentation, or no one can say who has a particular device. The root cause is lack of process: users can update hardware information without approval, or ownership changes are made in spreadsheets outside ServiceNow. The fix: implement a change request process for significant hardware changes (ownership, location, custodian changes). Require approval and maintain an audit trail.

Mistake: Ignoring Hardware Support and Warranty

Hardware has support contracts and warranties. When warranty expires, hardware becomes riskier (failures are not covered). When hardware falls out of support (manufacturer no longer provides updates), security and compliance issues may arise. If you do not track warranty and support dates, you cannot plan for refresh or manage risk.

The symptom: hardware fails and the company has to pay out-of-warranty repair costs; or hardware is out of support but still in use, creating compliance risk. The root cause is missing warranty and support data in Hardware Asset records. The fix: add warranty expiration date and support end date to Hardware Asset records. Set up alerts: when warranty is expiring, notify the owner or manager so a decision can be made about repair or replacement.

Mistake: No Regular Audit or Verification

As time passes, hardware inventory drifts from reality. Devices are moved without updating records, devices are stolen or lost, devices fail and are not removed from the system. Without periodic audits, the system becomes increasingly unreliable.

The symptom: inventory does not match reality, audit findings include missing or incorrectly categorised hardware. The root cause is no audit process. The fix: conduct regular audits (annually or semi-annually). Physically verify a sample of hardware: does the device exist, is the owner correct, is the location correct? Address discrepancies by updating records or finding missing devices.

Find out which process produced the bad record before you touch the data

A hardware register that fails its first real review is often wrong in a few predictable ways, and each way has a different owner. Laptops bought last quarter that never appear in the register point to a receiving step that was skipped. Records assigned to people who left a year ago point to a leaver process that never created a return task. Mixing those two problems into one “data quality” project is how teams can end up cleaning the same records every month, because the activity that broke them is still running. The first decision is diagnostic: for each failure you can see, which process let the bad record in? The broader lifecycle is laid out in the hardware asset management guides, which is a useful map before you start tracing individual records.

Three counts are cheap to pull and separate the causes well. Count the records with no custodian. Count the records whose custodian no longer holds an active account. Count the devices seen on the network that have no matching record. Records without a custodian usually come from stock that was received but never issued. Records with inactive custodians come from departures that were not tied to asset return. Discovered devices with no record usually come from purchases that bypassed the register, such as equipment bought on a card or charged to a project budget that nobody told the register about.

A diagnostic table that links each symptom to a cause and a first check

The table below is a practical starting point for a service owner who has just received a failed review. Each row starts from something an auditor or a finance analyst can see, names the process gap most likely behind it, and gives a single check that confirms or rules out that cause within a working day. The check is deliberately small, because a diagnosis that takes a month defeats the purpose.

The order of work that stops you cleaning the same records twice

Once the symptoms are sorted, sequence matters more than any single fix. The procedure below is ordered so that each step shrinks the work in the next one. Teams that clean first and change the process second usually see a tidy register for one quarter, followed by a slow drift back to the old state.

1. Agree the state definitions. Decide what counts as in use, in stock, in repair, retired and disposed, and write them into the register’s own guidance so that every record follows the same vocabulary.
2. Stop new errors entering. Require a serial number and a receiving record before any device is issued from stock. Enforce this by hand for a few weeks if the tooling is not ready.
3. Close the exit route. Tie leaver, move and role-change requests to asset tasks, so that a person’s change produces a list of equipment to return or reassign. If the lifecycle tasks need outside help, the service page for hardware, software and cloud asset lifecycle describes that work.
4. Reconcile against the network and the purchasing ledger. Resolve differences in batches grouped by cause, not device by device, using the matching rules set out in the note on how matching rules are set.
5. Only then merge duplicates and correct cost fields. Those edits are safer once the inflow and the outflow are stable, because a corrected record is less likely to be damaged again.

When a bulk correction makes the problem harder to see

A large correction is not always wrong, but there are situations where it hides what happened. If the register feeds a live decision, such as a refresh budget or a software true-up, a sudden shift in counts can cause a planning error that nobody can trace later. In that case, keep the original values beside the corrected ones, along with when and why each change was made, so anyone comparing two reports can see what moved. Do not delete a record that looks like a duplicate until you have confirmed that neither copy holds a live assignment, a maintenance contract or a financial posting. A record that looks redundant in the register can be the only link to an invoice that finance still needs.

Signals that the register is improving rather than being cleaned

A corrected register shows its progress in a few measurements that do not depend on a single review. Run the same three counts from the diagnosis every week, using the same query each time. The hardware KPI guide is the place to turn counts like these into measures a finance reader will accept. Watch whether those numbers fall after the intake rule goes live, not only after a clean-up sprint ends. If the clean-up numbers fall while the intake numbers stay flat, the team is working harder without touching the cause, and that is the signal to stop cleaning and return to the process.

Should the network or the register win when the two disagree?

Neither source should win for every attribute. The network is good evidence that a device exists, is powered and is connected. It is weak evidence of who holds the device or what it cost. Set a rule for each attribute: existence follows discovery, custody follows the approved assignment, and cost follows the purchasing record. A single rule that says the network always wins will hand the register to whichever tool reports most often.

Can a device without an owner stay in the register?

Yes, for a defined period and for a defined reason. Spare stock, lab equipment and shared infrastructure often have no personal custodian by design. The problem is an unowned record that nobody can explain. Give every unowned record a holding owner, such as the team that receives stock, and a reason code, so that the register can tell a deliberate blank from a forgotten one. Who holds that decision is a governance question, and the hardware governance model is where to settle it.

How far back should a reconciliation look?

Far enough to cover the purchasing data you trust, and no further. If the purchasing ledger is complete only from a certain date, reconcile from that date and treat older devices as a separate, lower-confidence population. Mixing the two produces counts that look precise and are not.

What happens to devices lent to a project and never returned?

Record the loan as a custody change with an expected return date and a named project owner. The same custody logic applies across the wider estate; the asset lifecycle article covers the lifecycle side of it. When the project closes, the owner either returns the device, transfers it to a new owner with a fresh assignment, or retires it. A device without any of those three outcomes is a typical source of the orphaned records that reviewers find.

Is it worth reconciling low-value items?

It depends on what the register is used for. For a warranty and security patching record, every managed device matters regardless of cost. For a financial record, the value limit below which items are not capitalised should be set by the finance owner, and low-value items can be tracked by quantity rather than by serial.