Implications not using Life cycle stage and status fields in BA form?

[dvass0107]

Hi,

Our org is in initial stage of setting up CMDB (manual data loads).  

They found lifecycle stage and status fields are not 100% matching to their needs and they want to settle with status field only.

In future if they need they want to use those fields.

Some questions below  I need to answer my customer, if you can help me.

1. Is it a best practice to ignore those two lifecycle stage and status fields?

2.  What are the implications if we ignore them now and re-visit them when situation demands.?

3. Also can they implement CMDB data manager without these fields? I found in docs that to implement CMDB data manager these fields to be in sync with CSDM standards. 

4. If using these fields are mandatory , can we add/remove option of these two dropdowns?

Regards,
Srinivas

[Dr Atul G- LNG · Accepted solution]

Hi @dvass0107 

The Life Cycle Stage represents the stage or phase of an overall life cycle process. A Life Cycle Stage

Status represents the status or step within a Life Cycle Stage. Together, these data elements provide an

overall place within a life cycle process.

• A life cycle stage is one of the broad phases that an object moves through, from inception or

procurement to operation and then to end of life.

• life cycle stage status is the particular status of an object within its current life cycle stage.

For example, a hardware CI in the Operational stage might change stage status over time from In Use to

In Maintenance to End of Support. A different hardware CI might go from In Use to End of Support

without ever having been in In Maintenance status.

NOTE: Life Cycle Stages and Stage Statuses are not editable. They are provided by ServiceNow in a

manner that allows for data integrity, accountability, and consistency across the different entities.

Unlike legacy state/status values, the new Life Cycle capability will display only those choice values that

align to the object you are managing. For example, tangible Assets and CIs will not display any choices

that do not align to tangible objects.

NOTE: There is no rush to use/migrate the new Life Cycle functionality. A mapping capability from/to

the legacy state/status attributes is available to populate the Life Cycle fields from legacy values but

no ongoing synchronization will occur after the Xanadu family release. It is recommended to evaluate

your dependencies on the legacy state/status attributes prior to enabling and migrating into the new

CSDM Life Cycle capability. These dependencies may include but are not limited to reporting, scripts,

business rules, and third-party integrations. Some product features such as CMDB Data Manager do

require the mapping to be enabled, v. Verify requirements with the features and / products you

intend to use.

[dvass0107]

Dr Atul,

Thank for nice explanation and write up. I have to present these pro and cons before the Customer and proceed with their consent. 

But if they insist on using CMDB Data Manager again which will touch base with these 2 fields, I have to provide them best approach

Reards,

Srinivas

[Dr Atul G- LNG]

Hi @dvass0107 

In that case, I would recommend using OOTB (out-of-the-box) values only. If you choose to use a static value, please note this as a risk, because for all services the values of these two fields will be the same, and practically, users will not fill in any purpose. It is better to use the OOTB values for now.

[Dr Atul G- LNG]

Hi @dvass0107 

1. Is it a best practice to ignore those two lifecycle stage and status fields?

Atul: It's not a best practice, but it’s also not mandatory to start using this from day one. Implementing CSDM isn’t straightforward, so ServiceNow recommends a step-by-step approach. If you’re not 100% sure, you can skip it for now and use it later.

2.  What are the implications if we ignore them now and re-visit them when situation demands.?

Atul: What I think is the major implementation challenge is that you need to work on the old data to set these values later.

3. Also can they implement CMDB data manager without these fields? I found in docs that to implement CMDB data manager these fields to be in sync with CSDM standards. 

Atul: Yes, you can use it, unless you want to base the data on these two fields

4. If using these fields are mandatory , can we add/remove option of these two dropdowns?

Atul: Yes, but that will create technical debt, because these two fields have backend relationships and might be used somewhere else. If you add your own values, they will be static only, without any underlying logic. You can go directly to the dictionary entry for the same field and add the choice there.