Using Lifecycle Stage / Lifecycle Stage Status
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-27-2022 06:05 AM
Hi,
I need guidance on the topic of Lifecycle Stage and Status. Assuming a fresh ServiceNow instance that doesn't have any objects that depend on the legacy status fields, would you use Lifecycle Stage & Status, enable those fields on all forms, disable all legacy fields and guide your users to use the new fields?
Also, in the docs page, "triggers" for certain stages are mentionned - for example, "Asset receiving" is listed as trigger for the "Inventory" stage of the physical CI lifecycle. Does this mean that the lifecycle fields should be made read only, and will only be changed by pressing buttons, or other actions? Or was this just guidance on how fulfillers should manually change the lifecycle stage & status fields, as in "once you receive this asset, manually advance the stage to inventory"?
Also, when I first saw the images, I thought we would be able to configure some sort of state machine with transitions. Is there any way (apart from maybe client scripts or ui polices) to limit transitions so that the lifecycle stages are run through in the correct order?
Thanks for your help,
Max
- 3,361 Views

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-27-2022 11:54 PM
Hi Max,
Good questions and here are my answers, but they just relay on my understanding and maybe ServiceNow will answer them differently.
1. Status field: Use an legacy one or the newer one:
I would say, it depends on:
- Companies internal wordings: Is there a need to have individual status choices? Yes, that the legacy field and do the mapping directly
- User friendly: In case the user should select the status manually, I would choose the legacy field and do the mapping. Because to choose always two attributes wouldn't be my preferred way to go, because every user would need to know, behind which stage, he can find the correct status.
2. Trigger of lifecycle status change
In my understanding it is a guidance for a better explanation, why you have the different stages and when to move from one to the other. But as said I do not think, it would be user friendly to work without UI actions, if you just want to use the lifecycle stages/status.
3. Limitation of transitions
I am not aware, that there are any OOTB limitations. And to be fair I do not know, if you really would like to have it. Because for every lifecycle you will have exclusions, why you can not follow every step.
I hope that helps. My suggestion would be to use the legacy field and to have in every solution design the life cycle mapping in mind, because in the background the new fields will be important. Also the article from
Hope my answer helps and I open for a discussion about that topic.
Regards Sebastian

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎05-01-2022 07:13 AM
Hi Max,
ServiceNow has started the migration towards the new Life Cycle Stage and Life Cycle Status attributes. Basically these attributes will be read-only as only by certain ' transactions' these atttributes may be touched. Goal of this is to get uniformity in the use of these statusses so all the ServiceNow applications can rely on the correct status settings.
For the migration from old (legacy) to the new attribites a transition/ translation table is available incl. automations around it. I do not know the exact details but I presume the can be found in the docs.
Ed