Use cases when I would like to update references between Asset and CI

[Hellfried]

Does ITAM or HAM have a way to handle re-use scenarios?

Our CI is a computer with a unique name, our asset is a piece of hardware, e.g. a Notebook.

When a users leaves the company, the hardware asset can be reassigned to another user - but with a new name, because the computer names have a connection to customers and departments. 

For me, this is the moment when I would like to create a new CI, leave the old CI (with the old name and software assignments and discovered properties) in "Retired" state - and re-link the asset (with the same hardware properties and serial number) to the new CI.

This is not optimally supported, it seems. 

The other way round, when a user gets a hardware replacement, all CI properties should remain: assigned software packages, company reference, just a new asset should be related to this CI ... 
Not possible, am I right?

[Itallo Brandão]

Hi @Hellfried ,

You are absolutely correct that these scenarios are not supported in the way you described. This is intentional. ServiceNow enforces a strict 1:1 synchronization between Asset and CI to prevent data corruption, specifically regarding Discovery and the IRE (Identification and Reconciliation Engine).

Trying to bypass this logic would be considered a bad practice as it leads to duplicate Serial Numbers and broken reconciliation rules.

Here is the breakdown of why the platform restricts this and the correct "ServiceNow Way" to handle it:

Scenario 1: Hardware Reuse (Employee Leaves -> New Employee)

• Your Idea: Create a "New CI" for the same hardware (same Serial Number) and leave the "Old CI" as Retired.

• Why this is dangerous: If you have two CI records (even if one is Retired) with the same Serial Number, Discovery becomes unreliable. When the scanner finds that Serial Number on the network, the IRE may throw a "Multi-Match" error or accidentally un-retire the old record, overwriting your data.

• The Best Practice (Rename):

  • Process: When the Asset is reassigned, you simply Rename the existing CI.

  • History: You do not need a separate record to track the "Old Name" or "Old Owner". That data is preserved in the Audit History (History > Calendar/List) of the single CI record. This maintains a clean "Golden Record" for that physical device.

Scenario 2: Hardware Replacement (User gets a new Laptop)

• Your Idea: Keep the "CI Record" (attributes, software) but link a "New Asset" (different Serial Number).

• Why this is dangerous: In ServiceNow, the CI IS the Hardware. Its identity is tied to the Serial Number/Mac Address. If you swap the Serial Number on an existing CI record, Discovery will see a mismatch during the next scan and will likely create a Duplicate CI for the new hardware anyway, leaving you with a mess to clean up.

• The Best Practice (HAM Swap):

  • Process: You must Retire the Old CI and create a New CI.

  • Entitlements: To preserve the user's setup, you use the HAM "Swap Asset" functionality. This process automates the retirement of the old device and transfers Allocations (Software Entitlements) to the new device so the user retains their licenses complianty.

Summary: Do not try to separate the Asset from the CI.

1. Same Hardware? Rename the CI.

2. Different Hardware? Retire old, Create new, and Swap entitlements.
   
   

If this explanation clarifies the architecture for you, please mark it as Accepted Solution.

Best regards, Brandão.

[Hellfried]

Thank you very much for your explanation!

My understanding of the concepts for Asset and CI was a bit different, I admit.

If this really is what the architects at ServiceNow built, it would create a considerable amount of manual work for the use cases I mentioned - even more striking for server CIs:

Example: Hardware re-use of a 4-node cluster of servers, each costing above 20000 US$, after a project is called off.  Renaming them is not enough. They have maintenance windows configured, are related to service models, have configured support groups and change groups, and are referred to by change requests that were planned for months ahead in time. 

All this would have to be removed if the same CI should become another server for another purpose operated by another team (and not to be included in the change next month).

I would rather create a new asset, and "hide" the old asset from discovery by removing or altering serial number, MAC addresses and name of the old CI.

When a server receives a hardware replacement, on the other hand, Discovery will automatically create a new CI after it takes its role. As you described. But then, all the relations and references must be copied from the old CI - this is why I asked if I cannot improve the process.
Not that easy, is your answer... and thanks again for the detailed descriptions.

BR Helfried

[Itallo Brandão · Accepted solution]

Hi Hellfried,

That is a fair and excellent point. You have correctly identified the divergence between End User Compute (Laptops) and Data Center Infrastructure (Servers).

While the "Rename" strategy is perfect for generic assets like laptops (where history is less critical), your Server Cluster scenario absolutely demands a clean slate. You cannot have a new project team inheriting the Change History, Incidents, and Maintenance Windows of a cancelled project.

Here is the refined architecture for your specific Data Center use cases:

Use Case 1: Server Re-use (Project A -> Project B)

Goal: Same Hardware, totally new Identity. Your proposed workaround: "Hide the old asset from discovery by altering serial number..."

Verdict: You are correct. In the Data Center world, if you must reuse physical hardware for a completely new logical purpose, you must perform a "Neutralization" of the old record.

1. Retire the Old CI.

2. Scrub the Identity: You must clear or suffix the Serial Number on the Retired CI (e.g., change SN12345 to SN12345-RETIRED).

3. Discovery: When Discovery scans the "wiped" hardware again (now with a new hostname/IP), the IRE will not find a match on Serial Number (since you changed the old one) and will correctly create a pristine New CI.

Use Case 2: Hardware Replacement (RMA / Upgrade)

Goal: New Hardware, keep the old Relationships/Business Logic. Your Pain: "All relations and references must be copied... not that easy."

Verdict: This is solved by CSDM Abstraction, not by HAM. The architectural fix here is to ensure your Business Services and Change Requests are not pointed at the Hardware CI, but at the Logical CI (Application Service or Cluster Node).

• Bad Architecture: Business Service -> Depends on -> Server Hardware A

  • (If Hardware A breaks, the relationship breaks).

• Good Architecture: Business Service -> Depends on -> App Service / Cluster VIP -> Runs on -> Server Hardware A

  • (If Hardware A breaks, you swap it for Hardware B. You only update the downstream "Runs on" relationship. The Upstream business logic remains untouched).

Summary:

• For Laptops: Rename.

• For Servers (Reuse): Retire, Scrub Serial Number (Neutralize), and Discover as New.

• For Servers (Swap): Use logical abstraction layers (CSDM) so the hardware swap doesn't disconnect the Service Map.

If this deeper architectural view aligns with your server management needs, please mark it as Accepted Solution.

Best regards,
Brandão.

[Hellfried]

Perfect - thanks for the summary; the abstraction level which I was missing in my own suggestion (using the configuration item as the abstractino) is much better represented by the Application level.