@Alec Hanson is correct. And without the status values synchronizing between the CI and the Asset, there just isn't any reliable lifecycle information. Which is why, from my perspective this feature just isn't ready for prime time -- even if you are on a brand new ServiceNow instance.
I was excited at first to hear that the multiple legacy values were being consolidated into a single lifecycle object, because there is great potentiality in this. Unfortunately the problem that still exists is what has plagued the asset and CI synchronization since the beginning. Because business rules can cause infinite recursion, there is a flag to skip the business rule execution on the second level trigger in the code. And thus, all of the field CANNOT stay in sync with one another. And because we have now added another set of fields, it actually just makes the problem even worse. To illustrate:
Update CI status --sync--> Update asset state --skip sync--> Update CI status
That's the basic idea. We want to update the asset state based on a change to the CI status, but we don't want to update the CI status based on the change to the asset state because that's redundant. So we set a flag to allow this business rule to be skipped on the second trigger. But the problem comes when there is another business rule that needs to run, because that business rule won't run either.
The first place we see this is in the convoluted relationship between CI Status and Hardware Status/Substatus fields. If you choose to use the Hardware Status/Substatus fields and perform an update, the asset State field will be updated, but that update will not in turn update the State field. So you end up with a CI that (for example) has a Status of "Installed" but a Hardware Status of "Retired". That may almost seem justifiable if you buy into the idea that you should know better to only report on the "correct" field for the class you are looking at, but I just don't buy that. If there is a field on a class, I should be able to use it or it shouldn't be there. If I want to report on all CIs across multiple branches, I should be able to do that. At the very least, it's extremely easy even for experienced users to mistakenly look at the wrong field and make the wrong decision because the values of the different fields are not kept in sync. And that's the problem that's been plaguing ServiceNow users (some without their knowledge): you just cannot rely on the status of assets and CIs to be in sync.
Enter CSDM Lifecycle. The idea is you want to have a single Lifecycle object that can be referred to by multiple objects, so that you can use a common language to talk about lifecycle, and this should make it easier to keep the lifecycle of the asset and CI in sync as well. Right? Unfortunately, no. Because now we have a problem in that we've just made the problem MUCH more complex. Not only do we now have to keep Asset and CI status in sync bi-directionally, across multiple legacy status fields depending on the CI class in use, we also have to keep CSDM Lifecycle in sync with all of those legacy status fields bi-directionally. No matter how you look at it, it is a logical problem that cannot be solved by a serial chain of business rule triggers. So this needs some major refactoring before it can be relied upon. Not only does ServiceNow need to refactor the various modules that rely upon lifecycle information from the legacy status fields so that they can look at either the legacy or CSDM lifecycle fields, thus enabling customers to smoothly transition, they also need to refactor the asset and CI synchronization to resolve the problem of fields not synchronizing.
From where I stand this is a complex problem that isn't going away any time soon, and the resulting issues will likely get worse before they get better. I hope I'm wrong, although I have conducted tests on a clean instance which have confirmed my findings, and it's been on my to-do list to write up an article about this. This one keeps me up at night, and the best I can surmise is that what we really need is some Lifecycle Manager script that oversees the lifecycle synchronization across all objects and all fields, regardless of the business rules that get triggered. And I'd love to hear from ServiceNow about whether they have acknowledged this problem and whether they are working on a solution.
In the meantime, I just don't think the CSDM Lifecycle is ready for use. At the very least, it should only be used in a read-only, unidirectional fashion, with direct status updates occurring only on legacy fields.
The opinions expressed here are the opinions of the author, and are not endorsed by ServiceNow or any other employer, company, or entity.
