- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-07-2024 02:31 PM
The life cycle mapping for Configuration Item: "Operational Status - Non-Operational" to "Configuration Item - Design - Build" not make sense for all use cases. For instance users may put a CI in Non-Operational status when the CI is turned down and pending retirement. I assume it's not best practice to update the lifecycle Control, but can someone tell me what the impact would be? What's the best practice in this case?
Solved! Go to Solution.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-08-2024 03:40 PM
It's a great question you are asking. I would consider what might come as part of CSDM 5.0... I understand that they are supposed to be announcing that this week at Knowledge 24.
The other consideration is to evaluate the Life Cycle Mappings table after upgrades/patches in your lower environments to see if a Life Cycle Mapping you created comes into conflict with any newly created or updated OOB Life Cycle Mappings.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-07-2024 05:57 PM
You should consider how the life cycles come into play from an Asset Management perspective. In the case of a "device" being turned off for retirement/disposal, the Asset State would change to "In stock" with a Substate of "Pending disposal". This would change the Hardware status of the CI to "In Disposition"
As seen in the Hardware life cycle the appropriate Lifecycle Stage and Lifecycle Stage Status would be "End of Life" and "Pending Disposal", respectively.
The Hardware life cycle information can be found at https://docs.servicenow.com/bundle/washingtondc-servicenow-platform/page/product/csdm-implementation...
There is not an entry in the OOB Life cycle Mappings configured for this scenario, so I would recommend creating one that supports the documentation noted above.
For example, the new Life cycle mapping
Table: Hardware [cmdb_ci_hardware]
Priority: 20
Legacy field name: Hardware Status
Legacy field value: In Disposition
Life cycle control: Hardware - End of Life - Pending Disposal
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-08-2024 08:09 AM
That's an interesting take. That covers hardware, but what about non-hardware classes, such as Application Services for instance.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-08-2024 08:34 AM - edited 05-08-2024 08:38 AM
For application services that are going to be retired, I am not sure why you would not directly retire them.
Also look at this in the Logical life cycle in ServiceNow Docs:
https://docs.servicenow.com/bundle/washingtondc-servicenow-platform/page/product/csdm-implementation...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-08-2024 09:30 AM
It's about tracking the decisions from divest (no longer investing) to executing plans to retire. . . Since Application Services are following the logical standard, the OOTB pending retirement is enough to satisfy the use case.
OK, back the second part of my original question. What is the impacts do I need to consider when creating a missing life cycle making? For instance, if I were to create a life cycle mapping for "In Disposition" for cmdb_ci_hardware as you suggested, wouldn't that screw up any OOTB logic that doesn't know to look for that life cycle status change?