CMDB CI Lifecycle Management (legacy)

  • Release version: Yokohama
  • Updated January 30, 2025
  • 6 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of CMDB CI Lifecycle Management (legacy)

    CMDB CI Lifecycle Management (legacy) enables ServiceNow customers to define, manage, and control the operational states and actions of Configuration Items (CIs) throughout their entire lifecycle. It provides mechanisms to tailor CI lifecycle management to business needs by specifying allowable states, actions, and transitions. Although the CMDB Data Manager now offers more comprehensive bulk lifecycle operations, CI Lifecycle Management remains critical for detailed operational state and action control, auditing, and integration with ITSM processes.

    Show full answer Show less

    Key Features

    • Operational States: Define and customize CI operational states such as 'Operational', 'Repair in Progress', or 'Retired'. Only one operational state can be active per CI, with priorities configured to resolve conflicts when multiple operators or automations attempt state changes simultaneously.
    • CI Actions: Define actions applicable to CIs during their lifecycle, including compatibility rules that allow certain actions (e.g., 'Patching' and 'Provisioning') to be applied simultaneously. Actions can also be restricted based on CI operational states.
    • Restrictions: Configure rules to restrict specific CI actions for certain operational states and prevent disallowed state transitions, ensuring lifecycle integrity and compliance with business policies.
    • Requestor Management: Manage operators and workflows applying states and actions with unique requestor IDs to track and audit lifecycle changes effectively.
    • Audit and Integration: Audit all operational state and action changes. Integrates with Incident, Problem, and Asset Management to enforce lifecycle rules, such as preventing incident tasks for retired CIs and synchronizing operational and asset statuses.
    • APIs and UI: Provides APIs for programmatic management of CI states and actions with enforcement of defined restrictions, and a UI to configure lifecycle rules and priorities.
    • Scheduled Job: A scheduled job maintains data integrity for lifecycle management tables and must be activated when implementing this module.

    Practical Use and Next Steps for ServiceNow Customers

    • Define and prioritize operational states to reflect your organization’s CI lifecycle and ensure consistent state resolution when multiple updates occur.
    • Create and manage CI actions relevant to your business processes, defining compatible actions where simultaneous operations are necessary.
    • Set restrictions to prevent inappropriate actions on CIs in certain states and block invalid state transitions, enhancing CI lifecycle governance.
    • Register requestors for workflows and non-workflow operators to enable controlled and auditable lifecycle operations via APIs.
    • Leverage integration points with Incident, Problem, and Asset Management to enforce lifecycle policies and maintain synchronization between CI and asset statuses.
    • Activate the CI Lifecycle Management scheduled job to ensure data integrity and smooth ongoing lifecycle management.

    Implementing CMDB CI Lifecycle Management allows for precise control over the operational life of CIs, supports compliance with ITSM policies, and provides auditability for lifecycle changes, which collectively enhance configuration management reliability and business alignment.

    From the time of its creation to the time that it is no longer needed, a CMDB CI would typically transition through several operational states while undergoing various operations. CI LIfecycle Management provides the mechanism to define states and actions for a CI and lets you apply appropriate actions based on a CI's state to tailor the management of CI lifecycle to business needs.

    The CMDB Data Manager is now a more comprehensive and integrated solution for managing CI life cycle operations such as deletion and archival, in bulk. For information about the CMDB Data Manager, see Working with CMDB Data Manager.

    Terms associated with CI Lifecycle Management:
    Operational states
    A set of states that a CI can be at such as 'Operational' or 'Repair in Progress'. A CI can be associated with only a single operational state at any given time. The choices for operational states are based on the operational_status field in the [cmdb_ci] table. There are several operational states that are defined in the base system such as 'Retired' and 'Repair in Progress'. You can modify this list to reflect operational states that are relevant in your business.
    Note:
    By default, Service Mapping is configured to ignore all host CIs for which the value of Operational status [operational_status] is not 1 (Operational) or the value of status [install_status] is 100 (absent). For additional information about this behavior, see Preparing customized ServiceNow deployments to work with Service Mapping [KB0647574] in the HI Knowledge Base.
    CI Lifecycle Management allows multiple operators and automations to simultaneously set different operational states of a CI. Since a CI cannot be associated with multiple operational states, it is important to configure each operational state with a priority. These priorities are then used in such situation to determine which of the operational states is the cumulative operational state.
    CI actions
    A set of actions that can be applied to a CI during its lifetime. You can define CI actions that are relevant in your business.
    Compatible CI Actions
    CI Lifecycle Management allows a CI to have multiple active CI actions simultaneously, however they must be specifically defined as compatible. By default, there are no two actions for a CI that are compatible with each other. You can change this behavior by specifying pairs of actions that are compatible and thus allowed to be applied simultaneously to a CI. For example, you can specify that the ‘Patching’ and the ‘Provisioning’ CI actions are compatible making it possible to apply both simultaneously to a CI.
    Not Allowed CI Actions
    By default, any CI action can be applied to any CI. You can restrict this behavior by defining a rule that an action is not allowed for a CI when it is in a specific operational state. For example, you can define a Not Allowed CI Action in which it is not allowed to apply the 'Provisioning' action to a Linux Server that is in a 'Non-Operational' state.
    Not Allowed Operational Transitions
    By default, transitions are allowed from any operational state to another. You can restrict this behavior by defining a rule that for a specified CI, a transition from a certain operational state to another operational state is not allowed. For example, you can define that for a Linux Server it is not allowed to transition from 'Repair in progress' to 'Non-Operational'.
    Requestor
    A requestor can be a workflow or a non-workflow operator that is trying to set operational states and apply CI actions. Each requestor has an associated requestor ID that is a GUID and that can be an active workflow context or a non-workflow registered operator ID.
    Lease time
    A time period that each requestor (especially non-workflow operators) can provide, during which a specified CI action is allowed to be active for a specified CI.

    CMDB CI Lifecycle Management provides a set of APIs to manage CI operational states and CI actions. And the UI where you define a set of rules to restrict certain operational state transitions and to restrict actions based on operational states. It also provides a mechanism to audit CI operational state and CI actions during the entire CI lifecycle.

    Providers such as automation, workflows, or Change Management can use CI Lifecycle Management as a mechanism to manage CI operational states and apply CI actions. By default, the behavior of CI Lifecycle Management has no restrictions on some operations, and full restrictions on other operations. The CI Lifecycle Management UI lets you modify this default behavior by specifying Not Allowed CI Actions, Compatible CI Actions, and Not Allowed Operational Transitions that restricts some operations and enables for others.

    With CI Lifecycle Management you can:
    • Manage CI operational states and CI actions throughout the entire CI lifecycle.
    • Manage CI operational state transitions.
    • Restrict certain operational state transitions.
    • Associate certain actions for certain CI types that are in specific operational state.
    • Restrict IT Service Management applications based on CI operational state.
    • Audit CI operational states and CI actions during the entire CI lifecycle.

    Lifecycle management APIs

    CI Lifecycle Management provides a set of APIs to manage CI operational state and CI actions during the entire CI lifecycle. All restrictions and allowances specified by rules in the UI are enforced when state management APIs run, and if an API attempts to perform a restricted operation, the operation is blocked and an error is logged.

    Registering requestors

    When using the lifecycle management APIs to apply CI actions, requestors are required to be registered and to obtain a requestor ID which is unique within the lifecycle management tables. To register and to obtain a requestor ID, non-workflow users should call the registerOperator API. Workflow users can use the active Workflow context as the requestor ID, and they do not need to explicitly call registerOperator.

    After completing the CI lifecycle operations, the requestor should call the unregisterOperator API to unregister. All the state management records associated with that specific requestor ID are then marked as inactive or they are removed by the CI Lifecycle Management — Restore Internal State Management Tables scheduled job.

    Integration with Incident Management and Problem Management

    A base instance includes the pre-defined CI action CreateTask used for creating a task for a CI. New instances have a pre-defined Not Allowed CI Action, specifying that the 'CreateTask' action is not allowed for any CI with a Retired operational state. This restriction is integrated with Incident Management and with Problem Management to prevent the creation of incident or problem tasks for retired CIs. The 'CreateTask' CI action is used as a reference qualifier to the Configuration Item field of the Incident/Problem tables. In a new incident or problem, CIs in which Operational Status is 'Retired' — are filtered out from the Configuration Item list on the form. For more information about reference qualifiers, see Reference qualifiers .

    Integration with Asset Management

    In a base system, a CI's Operational Status field and the Status/Hardware Status (if its hardware) fields are kept synchronized if one of the two fields' values is Retired. When Operational Status of a CI is set to Retired, then the Status/Hardware Status field is automatically set to Retired. In the opposite direction, when the Status/Hardware Status field of a CI is set to Retired, Operational Status is automatically set to Retired too.
    • When an Operational Status field changes from Retired to another status, the CI’s Status/Hardware Status field is set to Installed.

    • When a CI’s Status/Hardware Status field changes from Retired to another status, the Operational Status field is automatically set to Non-Operational.

      The change of state from 'Retired' to another state is seldom, and by default, the state is changed to 'Non-Operational'. However, this might not be the intended state for the record. Therefore, it important that administrators review and manage the state appropriately in this case.

    Whenever CI’s Status/Hardware Status changes, it is synchronized to the CI’s corresponding Asset State field, and vice versa — keeping the CI’s Operational Status and the CI’s corresponding Asset State synchronized.

    For more information about mapping Asset State and Substate fields to a CI's Status/Hardware Status (if its hardware) field, see Map asset state and CI hardware status. And for more information about retiring assets, see Retire assets.