Questions around Activating CSDM Lifecycle Standards

[Alec Hanson]

Hi,

I am wondering if anyone has had any actual success in migrating to the new Lifecycle Stage and Stage Status and if you have any advice or guidance.

I thought I would be in a good position to help get this working on a fairly new instance, but am finding a few inconsistencies that I am struggling with so any input would be great:

1. Inconsistency between Process Diagrams and Life Cycle Controls

The CSDM Life Cycle States process diagrams seems fairly straight forward, but then when I try to align these to what is setup in the Life Cycle Control (life_cycle_control) they don't seem to match. for example for Physical / Hardware CIs we have:

Yet in the controls table I see different status values:

Indeed neither Legal Hold or Quarantine are valid in the Controls table. This seems to be similar across the stages.

2. For new Instances, should old status still be used, or new Lifecycle stage/status

An interesting article by David Skowronek (https://community.servicenow.com/community?id=community_article&sys_id=88a3a7b6db708d10e515c22305961...) implied that the Legacy Status should still be updated and just the Lifecycle Stage/Status used as an output for report, scripts etc.

However when I try this within my PDI, any update to the Legacy status ‘install_status’ on a Server makes no update at all to the Lifecycle Stages

3.Life Cycle Mapping for CIs

I see we have different mappings for cmdb_ci_hardware (40 mappings) versus cmdb_ci_server (14).

cmdb_ci_server is a child of cmdb_ci_hardware so I assume that these 14 replace all 40 of those for cmdb_ci_hardware rather than being a combination?

4. Life Cycle Mapping Should these work OOTB

I am aware one of the first steps is to “Adjust and add any mappings as needed for your environment.” .

I understand this is required where you have any custom statuses, but is it expected that the OOTB default data is sufficient?

I am finding that the Lifecycle Stage / Status can become very much out of sync across a CI and an Asset with fields no updating as expected, and this seems to defeat the object of this CSDM holistic view.

5.Life Cycle Mapping fields

Priority: Does anyone have any examples of how this works as it is not clear to me

Reverse sync choice​: What does this field do?

Thanks in advance

 

 

[Jacques Clement]

Hello @Alec Hanson et al- I agree those Life Cycle fields are cumbersome, to say the least.

On your point #1, did you try to filter on the Hardware table, as well as all the parent classes? Some of the LC controls use inheritance, but not consistently. So it could be that some of the missing controls are present in e.g. cmdb_ci.

On #2, yes you must use the old statuses and map to the new ones; oob mappings don't work well enough to do a reverse mapping (CSDM > legacy) AND so many workflows, business rules and reference qualifiers simply ignore the CSDM LC fields and still rely only on the legacy ones. ITOM licensing true-up also use install_status to count subscription units.

On 3, yes there is inheritance, that's why not all mappings are copied across in subclasses. 

On 5, reverse mapping means you can update the legacy field status following a CSDM LC change. But there are limitations with that; 1 LC Control can be mapped to only 1 legacy value. This is annoying because there are more LC Controls than legacy values. So for example one can NOT map End of Life/Retired AND End of Life/Sold to operational_status = Retired (6).

Hope this helps.