The new CSDM 4.0 comes with several changes, and one of them is introduction of a new Lifecycle attributes. The following video by Scott Lemm and Mark Bodman provides nice insight into this topic and future product strategy.

What I would like to share in this article is personal insight into this topic, based on testing of the functionality and its limitations. There are few points I would to highlight:

• There is no hurry to migrate to the new functionality, unless you would like to utilize the new CMDB Data Manager
• You should start looking into this topic soon as the migration may require some time, planning and testing
• With highest probability you will not get rid of the current (various) status fields, they will co-exist and co-operate with the new Lifecycle

Why the current status fields will be still used?

• The Lifecycle values CANNOT be customized, in the future ServiceNow products will start to utilize them and any customization may break the logic / functionality
• Some of the current products have hard dependency to the current status fields:
• * Service Owner Workspace requires Phase [portfolio_status] and Status [service_status]
  
  • Application Services are dependent on Operational status [operational_status], as well as ITOM (especially Event management and Service Mapping)
• And I should not forgett the history - there are many customers live for a long time, with plenty of workflows, integrations, imports etc. where full migration to fixed list of baseline values and one unified atrribute would be extremely complicated

So how to ensure that you may get advantage of the new Lifecycle attributes without major effort? Answer is the Life cycle mapping. This feature is essential part of the overall Lifecycle functionality and enables bi-directional mapping of the current status fields to Lifecycle and back. Eventhough it sounds like a perfect solution, it has its limitations:

• Lifecycle mapping works with a single status attribute to Lifecycle and back

You may map Status [install_status] to Lifecycle and backup, but you CANNOT map combination of Status [install_status] and Operational status [operational_status] to Lifecycle. For that reason scenario where you have Status = Installed and you are using Operational status to further specify whether the CI is operational or not CANNOT be mapped to Life cycle.

• status attribute value to Lifecycle mapping is NOT 1:1

In order to achive perfect bi-directional mapping all mappings should be unique, 1:1. Unfortunately, this is not the situation and for some Lifecycle values there are several target status values. Example is Lifecycle "Ideation - Under Evaluation" that is mapped to 4 current Status [service_status] values. This is known limitations and the video I mentioned in the beginning states the same for Hardware status field.

How to get over those limitations? Solution is to make sure that every CI Class has exactly 1 status attribute that is editable, and all others are synchronized when needed, and especially read-only. The following picture shows usage of various status fields per CI type:

Green field "Primary" indicates attribute that is visible on the form and editable (based on ACLs etc.). This is the ONLY attribute that is used to set the status. Lifecycle mapping contains ACTIVE definitions only for this one primary attribute.

Yellow field "Synchronized from Status" indicates attribute that is not visible on the form and read-only but needs to be in line with primary attribute. Example can be hard dependency from ITOM. It may require Business Rule to implement this mapping.

This picture is one possible combination, you may decide to use Operational status instead of Status for e.g. Infrastructure CIs / Applications. Important is to understand what are the hard dependencies.

Solution presented in here:

• Ensures consistency of status values across multiple status attributes and Lifecycle, with fully predictable behavior
• Enables usage of the Lifecycle and CMDB Data Manager
• Does not break any hard dependency of the current ServiceNow products

There can be more solutions of the same problem, I am sure that solution I have presented now may not be the only one. Take as an input into your planning of migration towards the CSDM 4.0 and Lifecycles.

Want to know more? Check my next article CSDM 4.0 Life Cycle: How to implement it?.