From Laptop to License — Day 2 of 15
Hi everyone,
Somehow the original Day 2 / Post 2 article from my From Laptop to License series was archived, so I am reposting the same content again for anyone who was following the series or wanted to refer back to it.
Post 2: ITAM Data Flow Overview
Hello ServiceNow Community,
In Day 1 of the From Laptop to License series, I introduced the 15-post roadmap for understanding how ServiceNow ITAM connects HAM, SAM, CMDB, procurement, discovery, integrations, and governance.
Somehow the original Day 2 post was archived, so I am reposting the same topic again so the series can continue in order.
In this post, we will follow the complete ITAM data journey:
Request → Approval → Procurement → Receiving → Stockroom → Deployment → Asset → CI → Discovery → Software Installation → Entitlement → Reconciliation → Reclamation → Retirement
The purpose of this article is to explain how information moves across the ITAM lifecycle, where each record originates, which system owns each type of data, which ServiceNow records are created or updated, which teams participate at each stage, and what can happen when the flow breaks.
This post is an overview. The later posts in the series will go deeper into HAM, SAM, CMDB, integrations, governance, and maturity.
Why ITAM Data Flow Matters
ITAM is not only about creating asset records.
A reliable ITAM process depends on how information moves from one stage to another.
A request may be approved, but the asset may not be received correctly.
A laptop may be deployed, but the related CI may not be linked.
Software may be discovered, but the entitlement may not cover it.
A user may leave the company, but the hardware and software rights may still remain assigned.
This is why we need to understand the complete flow instead of looking at each record separately.
1. Request and Approval
The journey usually begins when a user requests hardware, software, or a SaaS subscription through the Service Catalog.
The request captures the business need:
Who needs the item, what is required, why it is needed, where it should be delivered, which department or cost centre is responsible, and when it is required.
In ServiceNow, this stage may involve:
Request [sc_request]
Requested Item [sc_req_item]
Catalog Task [sc_task]
Approval records
The request establishes the business context, but it is not the same as an asset.
For example, when an employee requests a laptop, the request explains the demand. The actual Hardware Asset is created or updated later when the device is received or assigned.
2. Procurement
After approval, the organization must decide whether the request can be fulfilled from stock or whether a new purchase is required.
When stock is not available, procurement may create a requisition, purchase order, purchase-order line, supplier record, quantity, cost, invoice, and contract reference.
In many organizations, procurement data may come from systems such as Coupa, SAP Ariba, SAP, Oracle, or another ERP platform.
This is where system ownership becomes important.
Procurement may own commercial information such as supplier, purchase order, invoice, quantity, cost, and contract reference. ServiceNow may use that information to continue the operational asset lifecycle.
A purchase order confirms that the organization ordered the item. It does not prove that the item was received, recorded correctly, deployed, or assigned to the correct user.
3. Receiving and Stockroom
Receiving connects the commercial transaction to the physical item.
For a laptop, the receiving team should validate the purchase order, record the serial number and asset tag, select the correct hardware model, confirm the quantity, and place the device in the correct stockroom.
Important records at this stage may include:
Hardware Asset [alm_hardware]
Asset [alm_asset]
Stockroom [alm_stockroom]
Hardware Model
Purchase Order and Purchase Order Line
This is one of the most important data-quality checkpoints.
If the serial number is wrong, Discovery may not match the device correctly later.
If the model is wrong, stock and refresh reports may become inaccurate.
If the stockroom is wrong, the organization may believe hardware is available in one location when it is actually somewhere else.
4. Deployment
Deployment moves the device from inventory into active use.
At this stage, the asset is prepared, configured, assigned to the employee, moved out of stock, and updated to the correct lifecycle state.
The deployment process may update:
Assigned to
Location
Department
Cost centre
State and substate
Stockroom
Deployment date
Related CI
A common issue is that the fulfilment task is closed, but the asset record is not updated correctly.
For example, the laptop may physically be with the employee, but ServiceNow may still show it as In Stock. That creates false stock availability and can lead to unnecessary purchases or assignment mistakes.
5. Asset and CI
After deployment, the hardware may be represented by both an Asset and a Configuration Item.
These records are related, but they serve different purposes.
The Asset manages ownership, cost, assignment, stockroom, warranty, lifecycle state, refresh, return, and disposal.
The CI manages technical and operational information such as device name, operating system, IP address, discovery status, service relationships, incidents, changes, and operational impact.
The Asset answers:
Who owns it, where is it, and what stage of its lifecycle is it in?
The CI answers:
How is it operating, what does it support, and what is its technical impact?
If the Asset and CI are not correctly linked, several downstream issues can occur:
Duplicate CIs
Software installations attached to the wrong CI
Incorrect incident or change context
Wrong user or location information
Retired assets still appearing active
Inaccurate reporting for HAM, SAM, and CMDB
6. Discovery
After the device is deployed, Discovery, SCCM, Intune, Jamf, or another endpoint-management source may report technical information.
This may include device name, serial number, operating system, IP address, last-seen date, management source, and installed software.
Discovery helps update the operational view of the device, but it should not be treated as the owner of every asset field.
For example, Discovery may provide technical inventory, while procurement owns purchase data, HAM owns lifecycle state and stockroom, HR owns employee status, and CMDB owns operational relationships.
This is why trusted integrations and field ownership are important.
7. Software Installation
Discovery and endpoint sources may identify installed software.
A Software Installation record shows that a software item was detected on a device or CI.
For example, Microsoft Visio may be discovered on the employee’s laptop.
This proves that software was found, but it does not prove that the software was normalized, connected to the correct Software Model, or covered by a valid entitlement.
8. Entitlement
A Software Entitlement represents the organization’s right to use a software product.
It may include the Software Model, publisher part number, license metric, purchased quantity, subscription dates, maintenance dates, contract reference, and upgrade or downgrade rights.
This is where procurement evidence becomes licensing rights.
A purchase order may show that the company bought software, but SAM still needs to understand what was actually purchased:
Was it user based, device based, core based, subscription based, perpetual, upgrade, maintenance, or part of a bundle?
Without correct entitlement data, reconciliation may produce an inaccurate compliance position.
9. Reconciliation
Reconciliation compares software rights with software consumption.
It looks at discovered installations, Software Models, entitlements, license metrics, purchased rights, allocations, install conditions, usage rights, and dates.
The result helps determine whether the organization is compliant, underlicensed, or overlicensed.
An entitlement existing in the system does not automatically mean the organization is compliant.
The entitlement must be linked to the correct Software Model, use the right metric, have valid dates, and cover the actual consumption.
10. Reclamation
Usage and reclamation help optimize the environment.
A product may be fully licensed but not actively used.
For example, Microsoft Visio may be installed or assigned to an employee who has not used it for months.
In that case, SAM may identify it as a reclamation candidate. After approval and removal, the right can become available for another user instead of purchasing more licenses.
Reclamation connects software compliance with cost optimization.
11. Retirement
The lifecycle does not end at deployment.
When an employee leaves or a device reaches the end of its useful life, hardware and software must be recovered or retired properly.
For hardware, this may involve return, inspection, wiping, stockroom update, CI retirement, disposal order, vendor handoff, and disposal evidence.
For software, this may involve removing allocations, revoking SaaS subscriptions, confirming uninstall, and returning rights to the available pool.
Changing an asset to Retired is not enough by itself.
The organization should be able to prove that the device was physically recovered, securely wiped, removed from active management tools, retired operationally, and disposed of with the required evidence.
A Simple Connected Example
Consider an employee who requests a laptop and Microsoft Visio.
The request captures the employee, location, cost centre, laptop model, and software need.
If the laptop is not available in stock, procurement creates a purchase order.
When the laptop arrives, the receiving team records its serial number, associates it with the correct model and purchase order, and places it in the stockroom.
During deployment, the laptop is assigned to the employee and linked to a CI.
Intune, SCCM, or Discovery later reports the device and identifies Visio as installed.
The Visio installation is normalized and connected to the correct Software Model.
The Visio entitlement provides the license metric and purchased rights.
Reconciliation compares those rights with consumption and calculates the license position.
If usage data later shows that Visio is no longer required, the license can be reclaimed.
When the employee leaves, the laptop is returned, the software allocation is removed, and the recovered right becomes available for reuse.
At the end of the laptop’s life, it is securely wiped, retired, and disposed of with evidence.
This is one connected ITAM lifecycle.
Common Gaps in the Data Flow
Some common issues seen in ITAM data flow include:
Missing purchase information
Incorrect hardware model
Wrong or blank serial number
Duplicate assets
Asset assigned to the wrong user
Asset still showing In Stock after deployment
Asset without related CI
CI without related Asset
Stale discovery data
Retired asset still reporting from Discovery
Software installation not normalized
Discovery Model not connected to Software Model
Failed entitlement import
Entitlement linked to the wrong product
Incorrect license metric
Reclamation candidate not completed
Asset assigned to an inactive user
Retirement without disposal evidence
These gaps usually affect more than one report or process.
For example, one wrong serial number may affect Asset–CI matching, Discovery, software installations, SAM reconciliation, offboarding, and refresh reporting.
Key Lesson
The most important lesson from ITAM data flow is:
A record can be correct by itself while the lifecycle is still broken.
A request can be approved, but the asset may not be created correctly.
A purchase order can exist, but the hardware may not be received.
An asset can exist, but the CI may be missing.
A software installation can exist, but the entitlement may not cover it.
An entitlement can exist, but reconciliation may still show non-compliance.
A user can be inactive, but hardware and licenses may still be assigned.
A device can be marked Retired, but discovery may still report it as active.
This is why ITAM should be viewed as a connected data journey rather than a set of separate records.
Foundation of Reliable ITAM
Reliable ITAM depends on four connected principles:
Clean Data
Models, serial numbers, users, locations, lifecycle states, installations, and entitlements must be accurate.
Trusted Integrations
Information must come from approved sources, update the correct records, and avoid unnecessary duplication.
Clear Ownership
Each system, field, record type, process, and exception must have an accountable owner.
Strong Governance
The organization must monitor data quality, investigate failures, validate corrections, and introduce controls to prevent recurrence.
Together:
Clean Data + Trusted Integrations + Clear Ownership + Strong Governance = Reliable ITAM Decisions
Key Takeaway
ITAM data flow explains how business demand becomes a commercial transaction, then a physical asset, then an operational CI, then a software-license position, then a reclamation or retirement action.
When each handoff is reliable, ServiceNow can provide better visibility into ownership, cost, compliance, usage, lifecycle risk, and operational impact.
Coming Next — Day 3
ITAM vs HAM vs SAM vs CMDB: Understanding Their Roles and Relationships
In the next article, we will compare what ITAM, HAM, SAM, and CMDB each manage, where their responsibilities overlap, and why concepts such as Asset and CI or Software Installation and entitlement should not be used interchangeably.
Which part of the ITAM data flow creates the most challenges in your organization?
#ServiceNow #ITAM #HAMPro #SAMPro #CMDB #HardwareAssetManagement #SoftwareAssetManagement #AssetLifecycle #Discovery #ServiceNowCommunity
Please mark this as Helpful if it helps.
If this addresses your question, please mark this response as Accepted Solution
or mark has helpful
if you find it helpful.
Thank you!
TejaswiniY
