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?“.