Thank you for your feedback.
Form temporarily unavailable. Please try again or contact docfeedback@servicenow.com to submit your comments.
Versions
  • London
  • Kingston
  • Jakarta
  • Istanbul
  • Helsinki
  • Geneva
  • Store
Close

CMDB CI Lifecycle Management

CMDB CI Lifecycle Management

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.

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 then 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. And when a CI’s Status/Hardware Status field changes from Retired to another status, the Operational Status field is automatically set to Non-Operational.

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.