Few queries on CSDM 4.0 Life Cycle stage and status

[Suggy]

We are on brand new Vancouver instance. Totally vanilla version. 

Questions:

1. Best way to use the 'life cycle stage and status' fields? - Can we just bring these 2 fields on the form and ignore ALL the legacy fields (remove all the legacy fields from the form)? or even today is is like we NEED to have the legacy fields on the form and use them to update?

2. Can we allow updating the life cycle stage and status fields and just rely on these fields for entire CMDB and Asset Management?

3. Suppose we have ACTIVATED by clicking on active button on Life cycle mapping table - this will do the bulk updates of legacy to life cycle fields. What if the mapping was wrong? We would correct the mapping, but how to do the bulk updates?

[Narsing1]

Here you go.

1. Yes.  Its good to bring these 2 fields on form and ignore all

2. Yes.  You can allow as that is the correct way forward

3. Life cycle mapping will not do the bulk updates. Before configuring this, need to sit with the functional / product owners/stack holders and confirm with them to make sure you are configuring this in a correct way.  The bulk updates can be done at any point of time if the things goes wrong via Fix scripts.  If you want to update the legacy field when there is a change in life cycle & vice-versa, use "Reverse sync choice" to true.

I hope this helps

Thanks,

Narsing

[Suggy]

@Narsing1 Thanks for replying. Have you implemented such way before? If yes, do you see any issues? 

[Narsing1]

On the 1st and 2nd items, 

• By default, Users who has cmdb_read role can have a read only access for list view & form view.  They can see these fields.  
• You may allow the write access to Data Stewards i.e. Owner of division wise Business apps and Application Services and Service Offerings
• Its better to cascade the field updates from Business app to Application services & Business Service to Business Service Offering and Technical service to Technical Service Offering (When AS/BSO/TSO Lifecycle not End Of Life)
• You may allow write access to Owned By User when you have any Data Certification tasks are in progress.
• Do not show the legacy fields like Operational Status, Install Status/State fields as the CSDM framework purpose is to get rid of Legacy fields.  You can still utilize these fields by using the Life cycle mapping by using the reverse sync.  If you have any discovery based updates happening to these tables, the mapping will take care of that to update the Life cycle.

I hope this helps.

Thanks

Narsing

[Jacques Clement]

Hello. I would advise against using CSDM Fields only.

Many OOB workflows, filters and reference qualifiers still use the legacy statuses and simply ignore Life Cycle Stage and Life Cycle Stage Status. For example, the reference qualifier in the Incident form filters out CIs where operational_status != "operational" and simply ignores life_cycle_stage. See below the reference qualifier for incident.configuration_item.

The other reason is that the Life Cycle Mapping has been designed with a Legacy -> CSDM use case in mind. Yes, it does support reverse mapping, but it has limitations and was designed to be a full bi-directional synchronization.

I would recommend using CSDM Life Cycle fields if you're planning on using CMDB Data Manager and/or Digital Portfolio Management. And if you do, populate the legacy fields and then use Life Cycle Mapping to keep the CSDM Life Cycle fields in sync.