Troubleshooting ServiceNow IT Asset Lifecycle Management: A Practical Guide

This guide covers common ServiceNow IT Asset Lifecycle Management faults: assignments that do not update, approval workflows that stall, asset data that does not match discovery, and license reports with wrong utilisation. For each fault it sets out where to look, likely causes, fixes and when to escalate.

Asset Not Assigning to the Correct Owner

Symptom: an asset is assigned to a user, but the assigned-to field does not update automatically, or updates to the wrong user. When you check the asset record, ownership is blank or shows the previous user.

Where to look: first check whether automatic assignment is enabled in your Asset Lifecycle Management configuration. Look for any business rules or flow designer flows that should trigger assignment when an asset is associated with a user. Verify that the user record is active and has the correct department and cost center attributes. If assignment is driven by HR integration, check the integration logs in the Integration Hub or MID Server logs to see whether the HR sync ran and what data it provided.

Likely causes: automatic assignment is not configured or is disabled. The HR integration is failing silently and not updating user attributes that the assignment rule depends on. A business rule has a condition that is no longer true (for example, it checks for an asset tag format that your newer assets do not follow). The user record is inactive or missing required fields.

Fixes: enable automatic assignment in the IT Asset Lifecycle Management module settings if it was disabled. Rerun the HR sync in the Integration Hub to refresh user department and cost center data. Check the condition on any asset assignment business rules to see whether they match your asset types. Create or update users in the system to ensure they have department and cost center set before assigning assets.

When to escalate: if the HR integration consistently fails, you may need to work with your integration team to debug data mapping or connection issues. If asset assignment depends on custom business logic that is not working, a ServiceNow developer may need to review the configuration.

Workflow Approval Stalls at Refresh or Handoff Steps

Symptom: an asset refresh or handoff workflow is created but sits in the approval state for days without moving forward. When you check the workflow activity log, it shows the workflow is waiting for approval but you cannot find the approval task.

Where to look: open the workflow instance from the asset record and check the Activity section for details on which approval task should have been created. Look at the approval assignment rules: workflows route approvals to a group or a specific role. Verify that the group has members and that those members have the necessary role assigned. Check the approval task table directly and filter by the workflow ID to see whether the task was created at all or whether it is stuck in a pending state.

Likely causes: the approval group is empty or members have been removed from the group. The approval rule condition is not matching your assets (for example, the condition checks for an asset type that does not match). The person assigned to approve the task is on vacation and has not delegated approval authority. A task was created but the URL or link in notifications is broken, so approvers cannot find it.

Fixes: check group membership and add members if the group is empty. Verify the approval rule condition matches your asset type and cost center. Set up an active delegation rule or escalation process for when approvers are unavailable. Test the approval task link by clicking it from a notification to ensure it works.

When to escalate: if the workflow is complex and multiple approval steps are stalling, a workflow designer or developer should review the flow to check for logic errors or missing error handling. If this is blocking asset handoff operations, prioritize escalation to unblock the process.

Asset Data Not Matching Discovered Inventory

Symptom: when you compare reports of assets in IT Asset Lifecycle Management against output from your discovery tool, the numbers do not match. Some assets appear in discovery but not in the system. Others are in the system but show incorrect status or location.

Where to look: check the most recent asset discovery run to see how many assets it found and how many were imported into ServiceNow. Many discovery tools allow you to export the raw discovery data and compare it to the import result. Check whether a discovery import workflow exists and whether it has error logs. Look at asset records that exist in the system to see whether the discovered_by or discovery_source field is populated, which indicates they came from an import.

Likely causes: the discovery tool does not have network visibility into part of your environment (VLANs, cloud subnets, remote office networks). The asset import job runs but imports fewer records than it found because duplicate detection is too aggressive and merges new assets into existing ones. Asset status is not updating after discovery runs because the workflow is not configured to update status based on discovery results.

Fixes: verify discovery tool network connectivity and credential access to the parts of your infrastructure it is supposed to scan. Check the duplicate detection rules in the import workflow to see whether they are correctly configured. Adjust the rules if they are merging distinct assets or skipping assets you need. Verify that the import workflow has a step to update asset status fields based on what was discovered.

When to escalate: if your discovery tool has limited connectivity to critical parts of your environment, you may need network or security team involvement to open access. Large discrepancies between discovery and the system may require importing a fresh baseline of assets from discovery and reconciling the difference.

License Count Reports Show Incorrect Utilization

Symptom: you run a software license utilization report and the numbers do not add up. The report shows more installed instances than licenses purchased, but auditing individual software installations shows no obvious problem.

Where to look: check how software discovery is feeding into the license matching logic. Some discovery tools report multiple instances of the same software on one device because they detect the software in the registry and also in the installed programs list. Check the software discovery configuration to see whether it is configured to deduplicate. Look at the license entitlement table to see whether licenses are configured correctly with name matching the software names that discovery provides.

Likely causes: software discovery is finding duplicates and counting the same installation multiple times. License entitlement names do not match discovery software names, so the system does not recognize that a discovered instance corresponds to a purchased license. A custom field on the license entitlement is being used to track utilization but is not being updated by the import workflow.

Fixes: configure the software discovery tool to deduplicate software instances on the same device. Check and update software names in the license entitlement table to match what discovery reports. Verify that the import workflow has a step to match discovered software against license entitlements and update the utilization count. Run the matching logic again and regenerate the report.

When to escalate: if the license matching logic involves complex custom code or multiple business rules interacting, a developer should review the logic to find the calculation error.

Common Pitfalls and Prevention

A frequent mistake is creating asset workflows without testing them end-to-end before deploying to production. Set up a test asset and manually step through the entire workflow to make sure approvals route correctly and notifications include the right links. A second pitfall is assuming asset discovery data is authoritative without validation. Always compare discovery output to what you know is actually in your environment, and handle discrepancies before you use the data for compliance decisions. Finally, do not let asset data drift: schedule regular syncs with HR systems and regular re-discovery of infrastructure so your asset inventory stays current.

Problems that look like data faults but start in the configuration

Several symptoms that surface in asset reports are caused by how the platform is configured rather than by bad records. The checks below run in the order that finds the cause fastest, and each one can be done by an administrator without a code change.

Why the time zone case catches teams out

A warranty date is a calendar date, but the platform can store it as a date and time and display it in the viewer’s time zone. A report run in one region can show an expiry that falls a day earlier than the figure shown to a colleague elsewhere. The fix is to agree which time zone governs warranty and contract dates, and to store those dates as dates rather than date-times where the platform allows it. Until that decision is made, two people will both be right about different numbers.

When to escalate and what to send

Escalate to the platform team once the first check has been done and the cause is still unclear, and send them three things: the exact report or record, the filter or rule being tested, and the result of the check. A vague report that the numbers are wrong often costs more time than the investigation itself. Where the cause is a credential or a schedule, the owner of the integration should be told in the same message, because they are often the only person who can rotate the credential safely.

Checks to repeat after a fix

• Confirm that the affected report returns the expected count for a small set of records you can verify by hand.
• Check a record created before the fix and one created after it, so that the change is not only visible on new data.
• Look at the audit history of the configuration change so the reason for the fix is recorded with the approver’s name.

Frequently asked troubleshooting questions

Why does the same report give different totals for two administrators?

Often because the two runs use different filters or different time zones, or one of them is looking at a saved view that has been edited. Compare the saved configuration of each report before comparing the numbers.

Should we rebuild the asset data if duplicates keep appearing?

Rarely as a first step. Fix the matching rule so new duplicates stop, then merge the existing ones through a controlled process. Rebuilding from scratch throws away the history that the duplicates still hold.

How do we know an integration failure has been noticed?

Check whether a failure produces an alert that reaches a named person. An error written to a log that nobody reads is not a notification. The integration error handling article covers how a support team decides what happened and what to do next after a failure.

Next step

Including the report definition and one example record makes the cause easier to trace. Regression checks for any fix belong in the testing and acceptance checklist.