Lifecycle Stage and Status for New Xanadu instances doesn't get set by default

[Jyo2]

I recently watched the  CSDM Lifecycles: Aligning and Transitioning to Xanadu session  and I found it very helpful for customers who followed the legacy states. 

However, I’ve noticed a few gaps within  new Xanadu+ instances (whether PDI or not), specifically with asset states/substates or CI states.

Here are some observations:

1. The LCSS fields are not available on the Classic view of the asset/CI form 
2. The LCSS fields are not available on the Workspace view of the asset/CI form
3. Plugins like Procurement, even though on Xanadu, still update the legacy state/substate fields. However, these fields do not update LCSS fields on new X+ instances because legacy sync is not on.
4. It’s possible that SGCs or 3rd-party store apps certified for Xanadu may still update the legacy fields, though I haven't confirmed this yet.

If we need to enable legacy sync to address points 3 and 4, what is the guideline to address the discrepancy report for the OOB status/substatus. Aside from the DR standby status, which is being considered as a work-in-progress item, do  any recommendations for a corresponding Lifecycle Control record in this scenario? Screenshot below - 

[Mathew Hillyard]

Hi @Jyo2 

Yes, you are correct, the fields aren't placed on the forms by default, even with a new Yokohama instance, or at least not consistently. Business Application, for example, does include them by default.

In terms of recommendations, if they're not baseline legacy values, which should already be mapped, it's a bit of a guessing game to either create a mapping or a life cycle control. The CSDM V4 White Paper contains a useful visual representation of the life cycle values. I'd just make sure everyone agrees on a specific Life Cycle Stage and Status mapping so there are no issues once activated.

The challenge with this is that activating life cycle mapping is a one time switch on - if you get new legacy values later on, then they won't be sync'ed. So, governance is required to ensure that the legacy status values in play remain the same, and that if any 3rd party apps create new status choices you'll need to modify them to accepted values (if possible and doable).

I hope this helps!
Mat

[Jyo2]

Thank you for your response, Matt.

I was  hoping to have greenfield customers start afresh with the LCSS approach. Since newer instances still have these legacy statuses, customers are often defaulting to them, which leads to backlogged initiatives where they need to later work on mapping and syncing these statuses. Additionally, the legacy mapping rules still run every time an asset is updated, which results in unnecessary database calls that could be avoided.

I was thinking that it would also be helpful to have an info message or link above the legacy status to encourage customers to transition to LCSS and avoid future mapping sessions, so that they can take the right steps towards following  CSDM.

I appreciate your thoughts 🙂 ! 

[Jyo2]

@Mark Bodman  I would love to get your thoughts on LCSS initiatives for new customers who never used legacy values.
Thank you.

[PatrickMayer_CH]

@Mark Bodman Me too, it seems to mee that this is currently a blackbox what is happening in the background (Business Rules, Inheritance, Script Includes, what is triggering what and so on)

Any help, guidance is much appreciated