
- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
on 04-21-2022 05:31 AM
A few months ago, I published the community article „CSDM 4.0: (any) Status attribute vs. Life cycle“, which describes the way to approach „legacy“ status attributes and the new Life Cycle. In this article, I will focus on how to get the new Life Cycle attributes in use.
Phase 1: Configure the primary attribute and synchronization to secondary ones
The target of this phase is to enable status management of Configuration Items by a proper status attribute. As I wrote in the previous community article, every CI Class should have only one editable status attribute, and all others are synchronized when needed. Secondary - synchronized - attributes should be read-only.
Enabling of the primary status attribute may include – but is not limited to - the following activities:
- Adding the primary attribute to the form(s)
- Hiding the secondary attribute(s) and modification of the ACLs to make them read-only
- Create a Business Rule for synchronization between the primary and secondary attribute(s)
- Analysis of the current processes, workflows, scripts, import sets etc. that modify the secondary attribute and change to the primary one and adjust them accordingly
The last point may require a deeper analysis of many objects, depending on today's status attributes. If you are already using the primary attribute, no deep analysis is likely required.
An analysis may include – but is not limited to - the following objects:
- Workflows
- Business Rules
- Script Includes
- Client Scripts
- UI Policies
- Identification and Reconciliation Rules
- IntegrationHub ETL Imports
- Import Sets
- CMDB Interfaces and integrations
Special attention should be for Script Includes, where GlideRecord.setWorkflow(false) may be used and block proper status synchronization to the secondary attribute(s). Similarly, Import Sets may use the do not run Business Rules option.
Even though it is mostly technically oriented, this phase may include activities that need proper communication with stakeholders. Change of the (primary) status attribute requires communication with all CMDB-related stakeholders, especially those responsible for managing Configuration Items. In addition, various materials such as training materials, knowledge articles, onboarding instructions, playbooks, documentation/guides for ServiceNow developers, etc., need to be reviewed and updated.
Phase 2: Configure Life Cycle Mapping and enable synchronization to the Life Cycle attributes
All the activities being part of phase 1 enable you to leverage the Life Cycle attributes that are prerequisites for additional features, such as CMDB Data Manager. Activation of the CSDM Life Cycle is described in the documentation site https://docs.servicenow.com/bundle/sandiego-servicenow-platform/page/product/csdm-implementation/tas...
This phase is technical only, without end-user/fulfiller visibility. As the activation of the Life Cycle will do a one-time population of the Life Cycle attributes for all CMDB records, it needs to be properly planned and tested.
The most important is a proper population of the Life Cycle Mapping [life_cycle_mapping] table. This table contains a mapping between your primary “legacy” attribute and the new Life Cycle attributes, including the reverse mapping option (Reverse sync choice attribute). The Life Cycle Mapping table is pre-populated by recommended values, and for many tables, it contains two sets of mappings: one for State and the second for the Operational status.
As I described in the previous article “CSDM 4.0: (any) Status attribute vs. Life cycle“, I recommend having only 1 set of attributes for each CMDB class active in the Life Cycle Mapping table – the one for your primary status attribute. Why have a single set of active mapping? Manageability and predictability of the results. Secondary attribute(s) are synchronized automatically based on the primary one, so why have a mapping for this? It may lead to confusion.
Activities related to Life Cycle mapping may include – but are not limited to:
- Identify and document all custom states
- For each custom state, define a mapping to the baseline Life Cycle value
- Make sure that the Life Cycle Mapping table contains only one active mapping per CMDB class
- Enable the Life Cycle mapping
- Validate results
All the activities must be done in the sub-production environment first, with proper testing of all (critical) business processes.
Phase 3: Enable the CMDB Data Manager
Once you complete phase 2, you are ready to leverage the CMDB Data Manager. CMDB Data Manager is a policy-driven framework for managing CI life cycle operations such as retirement, archival, and deletion, in bulk. The CMDB Data Manager is a comprehensive and integrated solution that scales to large CMDBs and copes with rapid changes in a cloud-based world.
Today, a CI retirement process is often implemented as a custom solution, depending on scheduled jobs, business rules, and overall custom logic. Using the CMDB Data Manager, you may have the whole CI life cycle controlled from a single place, with:
- Unified retirement process with embedded approval workflow before the actual retirement
- Archiving of the retired CIs without orphan records
- Deletion of the archived CIs, if required
If you have already tried to retire CMDB records, you may know it is not enough to retire the CI record itself. There is a need to retire many other records, such as relationships, various many-to-many table records, defined child CIs, etc.
From my personal experience with such a process (Archive => Delete), you may leave plenty of orphan records that may cause issues/data inconsistency. Further cleanup is usually very complicated. The CMDB Data Manager mitigates this risk, as the baseline archive rule (Archive Configuration Items) contains more than 100 dependent archive rules responsible for cleaning up all those additional tables.
Where to begin? With the Configuration Management process. The majority of the customers keep the retired CIs in the CMDB without archiving and deleting. Deleting of retired CIs should be considered carefully regarding the possible impact on processes that may consume those CIs – especially ITSM processes. On the other side, archiving will move the records from the „live“ tables into archive tables while keeping the archived records still accessible, if required.
What to consider to using the CMDB Data Manager?
- What CIs should be retired? When?
- Do you need a special approval process? Who should approve it?
- What happens as a part of the retirement process? Do you add „retired_“ prefix into a CI name, clear some values, relationships etc.?
- Before moving to the archive, how long should the retired CIs stay in the „live“ tables?
- What needs to be archived together with the CI? Baseline „Archive Configuration Items“ Archive Rule contains more than 100 definitions; do you need to add some more?
- Should the archived CIs be accessible for all fulfillers (the same ACLs as „live“ tables), or should access be limited?
- What happens with archived CIs? Should they stay in the archive forever? Do you want to move them into external storage or delete them? When?
- And likely some more questions ...
Phase 4: What’s next?
Unified Life Cycle management across all CMDB, including Products, provides higher manageability of your implementation. Your reference qualifiers may be simplified, working with a single set of attributes across multiple objects. Define and implement once; use many times.
Conclusion
The migration towards the Life Cycle may sound complicated, but the steps described in this article can be done one by one, without any big bang. In the future, ServiceNow products will start depending on the Life Cycle attributes instead of the current dependencies on Operational status etc. I hope that this article will help you with your migration path toward the CMDB Life Cycle.
Are you interested in migrating your custom data model toward the CSDM-compliant one? You may check my other article „CSDM: How to get there?“.
- 12,792 Views

- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Nice summary of the steps. I often see, that companies using the operational status for the CI, which is not mapped to the asset status field. This would get a bigger problem, when the lifecycle stage and status for the two primary fields map differently. Because of that I would suggest to add one point: Make sure your primary status fields from your asset and CI are mapped to each other and will be mapped to the same lifecycle stage/status. OR Deactivate the mapping of the primary fields and do it over the lifecycle stages/status. But this will only work, if the bi-directional mapping is supported by ServiceNow.

- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Hi @David Skowronek ,
Many thanks for the great articles, I am still digesting them to plan out the use of the new Life Cycle standards.
However I am not really sure I get the "Reverse sync choice" attribute. The principle of it I do get, that it determines if the mapping is used in reverse - i.e. CSDM to Legacy.
But I am struggling to get this to work.
Is my understanding correct?
Cheers

- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Hi, @alecH . Thanks for your feedback. Reverse sync means that update can be bi-directional. From Legacy attributes to Life cycle, but also backwards, from Life cycle attribute to Legacy. While the direction Legacy => Life Cycle is without any problem, it does not apply to reverse option. See the following example. There are multiple values for Legacy Hardware status mapped to the same Life Cycle Control. If you would work with Life cycle control directly, you cannot determine the right Hardware Status value as multiple options exists.

- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Hi @David Skowronek , Thanks.
So with that in mind do we believe there is actually any benefit in the Life Cycle => Legacy yet? Or is it left to the customer / client to determine how they what it to work in reverse and update the mapping accordingly?
As the CMDB Whisper suggested on another post, is the actual advice at present to just use this Legacy => Life Cycle and have the Life Cycle fields as read only, being use for reporting, read in workflows, but not for updating?
Thanks

- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Thanks @David Skowronek. I have an issue with the way Life Cycle Mappings have been designed in the first place, but maybe I'm overlooking something.
Unless I'm wrong, the feature assumes that legacy fields are the main ones, with an objective of keeping CSDM Life Cycle values in sync. I hear that reverse syncing exists, but it has flaws and it does not consider the use case where the customer (especially on a fresh instance) decided to maintain Life Cycle fields and hope for the legacy fields to be kept in sync.
This is why it's OK to have multiple legacy values updating Life Cycle fields, assuming reverse_sync is false (see below), but not the opposite. However for customers willing to maintain Life Cycle fields as their master (especially through integrations), this is a show stopper as many oob processes assume the legacy fields will be populated with correct values. It's a real bummer... or do I miss something?
Thanks.

- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Hi, @Jacques Clement, you are right with the reverse sync. Mapping between baseline "legacy" status fields and Life Cycle is not 1:1, it is N:1. Whether it cause a problem, depends on products and attributes being used. I am currently working a new ServiceNow customer, where we decided to use the Life Cycle as the main status attributes, and we are doing sync to the legacy ones. Customer does not want any customization, therefore this approach works ... with some limitations as you mentioned above, in the unclear reverse sync. We must carefully analyse the impact, and come with e.g. business rule functionality if something is an issue.

- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Odly enough, I am dealing with the exact same scenario as you. It was also agreed not to customize the way mapping works oob and accept the limitations.
Thanks for taking the time to comment.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Hi,
In the mapping table, I see there are mappings for the cmdb_ci class.
I assume that it is used as a fallback if a class do not have a dedicated mapping defined. The system crawl the list of parent classes until it find a mapping.
So having mappings only for the class cmdb_ci should be enough to manage all the CIs, but when I disabled all the mapping not for cmdb_ci, the lifecycle attributes get the value "To Be Determined".
I've to define a mapping for each class itself to have the mapping working.
Is my first assumption, about the fallback, wrong?
Thanks

- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Hi, @Amar_Be . Your assumption is correct, it works with inheritance. If it does not exists for the given class, it goes to its parent.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Hi @David Skowronek , @Amar_Be
If the fallback is right , we have activated CSDM lifecycle but for certain class of CIs, the lifecycle was set to "to be determined" for retired CIs of some classes. We do have a mapping for the retired CIs in base table. If there are no specific mapping for this tables then it should fallback to base table right? Its not happening can you please help?
Please see below.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Hi Vennila,
If you have disabled some mapping rules, this block the inheritance.
You must activate each rule and delete the one you don't need. Deactivating leads to error in the mapping process.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Hi Amar,
Thanks for the reply. Yes , I did check the mappings again and was able to find that the retired mapping was deleted for application class which resulted in this issue.
Thanks,
Vennila

- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Hi @David Skowronek, great article it really helps getting the migration done.
But I can't get it to work, maybe you can advise.
The cmdb_ci_circuit table has a specific status field called ABC Status (u_abc_status).
I create a mapping for the circuit class using ABC Status to OOB cmdb_ci class life cycle attributes.
When I change the ABC status, the life cycle status and state record changes as expected. But when I change the Life cycle attributes, it does not change the ABC status.
Any tips (anyone)?
Cheers,
Arno