CI Hardware status & Sub Status mapping to CSDM Lifecycle fields on Computer Class

[Vikrant Kulkarn]

So here is the deal, while implementing HAM, the asset state and asset sub state granular status cannot be mapped to CI Lifecycle fields via the Install Status mapping from Asset states. For this reason we looked at using the Hardware status and sub status fields and to my surprise their combination works well in making sure the Asset granular status can be set on the CI lifecycle field as below.

Asset Lifecycle Stage & Lifecycle Stage Status <-> Asset State & Asset Substatus <-> Hardware Status & Substatus <-> CI Lifecycle Stage & Lifecycle Stage Status. 

So now I have 2 questions.

1) Hardware Status & Substatus fields are regarded as legacy fields and have been advised as not to be used in any case? 

Now if they fit the bill and use as is OOTB is to advisable to still use them? What's the technical impact of using them in the future. 

2) To make sure unique updates are tracked, we plan to make the install status and the Operational status fields on the Hardware classes as read-only? Logic behind this is that anything to do with Hardware Assets need to happen on the alm (asset side of HAM Pro) and not on the config side. 

Now, is there any issues in making these fields read only for the Hardware class (computer specifically)? 

Dumb questions but I struggle not to use hardware status and Substatus when they work perfectly well with the business requirements? 

Appreciate the expert insight on this. 

Thanks 

Vik

[HIROSHI SATOH]

While using legacy fields and making certain fields read-only might introduce some technical considerations, their effectiveness in meeting your specific requirements can outweigh potential risks. It's essential to carefully evaluate the trade-offs and ensure that your solution is well-documented and maintained to minimize future challenges.

Question 1: Hardware Status & Substatus Fields

The primary concern with using legacy fields is potential compatibility issues in future ServiceNow updates. While these fields are unlikely to be removed, their functionality or relationships with other components might change. It's essential to monitor ServiceNow release notes and upgrade documentation to stay informed about any potential impacts.

Question 2: Making Install and Operational Status Read-Only

Read-only fields for Hardware: Making Install and Operational Status fields read-only on Hardware classes (specifically computers) can be a reasonable approach to ensure updates are tracked and managed consistently through the Asset Management module.

Potential issues: While this approach aligns with the principle of managing hardware-related changes in the Asset Management module, it's crucial to consider the following:

• Workflow dependencies: Ensure that any workflows or scripts that rely on these fields are updated to reflect their read-only status.
• Customizations: If you have custom applications or integrations that interact with these fields, they may need to be adjusted to accommodate the change.
• Future requirements: Consider whether future business needs might require the ability to modify these fields directly on the CI. If this is a possibility, you might want to explore alternative approaches or design your solution with future flexibility in mind.