CMDB Data Manager is a policy-driven framework for bulk management of CI life cycle operations such as deletion, archival, and attestation. 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.

Large CMDBs can over time accumulate large amounts of stale CIs that can impact overall performance. Custom mitigating solutions can be difficult to develop and to maintain, and are also prone to errors. The CMDB Data Manager is the tool where you can create, publish, and manage policies. Create policies to automate and govern CI life-cycle operations to help maintain the CMDB in a healthy and efficient operational state.

Use the CMDB Data Manager to create policies that represent your organizational processes for managing the life cycle of CIs such as:
  • Retire all computers without owners that were created more than a year ago ('Retire' policy type).
  • Archive all Linux servers in the Seattle datacenter that haven't been updated for six months ('Archive' policy type).
  • Delete all containers that haven't been discovered in the past week ('Delete' policy type).
  • Attest all the CIs in a specified location (Attestation policy type).
  • Approve cascade-delete, archive, or retire life-cycle tasks generated by dependent CI management.
  • Delete orphan, stale, or irrelevant records in non-CMDB related tables. The non-CMDB Related tables in the Related Entry [cmdb_related_entry] table have references to CMDB tables. A CI in a related table can, for example, become orphan if the referenced CI in the CMDB is deleted ('Delete CMDB Related Entry' policy type).
  • Certify that attributes have a specific value required for the business.

You can apply CMDB Data Manager policies only to classes that extend the Configuration Item [cmdb_ci] table. Therefore, you can't use the CMDB Data Manager to manage classes such as those that were imported by CMDB CI Class Models.

CMDB Data Manager experience in CMDB Workspace

You can use the CMDB Workspace landing page and its views to fully administer CMDB Data Manager, access high-level analytic and counts for its policies and tasks, and review your tasks. For information about using the CMDB Data Manager in CMDB Workspace, see CMDB Data Manager experience in CMDB Workspace.

CMDB Data Manager on Core UI (UI 16)

Starting with the Washington DC release, CMDB Data Manager on Core UI (UI 16) is being prepared for future deprecation. It will be hidden and no longer activated on new instances but will continue to be supported. CMDB Workspace provides the latest experience for this functionality.

CMDB Data Manager built on Core UI (UI 16) is available by navigating to All > Configuration > CMDB Data Manager. For information about using the CMDB Data Manager legacy build on Core UI, see CMDB Data Manager (Core UI).

Terms

Policy

A CMDB Data Manager policy captures the overall management plan for a life-cycle event, such as CI retirement. A policy is associated with a subflow (the policy subflow) which creates the tasks (the policy tasks) for the target CIs of the policy. A policy is configured with a policy type and the policy tasks perform operations associated with that policy type, such as archiving or deleting a CI record. Also, you can configure a policy to require an approval.

The policy type, policy subflow, and policy tasks are all aligned to a specific CI life-cycle event. For example, a policy set with the delete policy type is associated with the delete subflow, and its policy tasks handle the deletion of CIs.

A daily scheduled job processes all published CMDB Data Manager policies.

Policy subflow

The policy subflow contains the underlying logic to process a life-cycle event such as retire or delete. If the policy is configured to require approval, then the policy subflow runs only after a policy task is approved.

The base system provides several common subflows such as delete, archive, and retire, which you can use with policies. You can also create custom subflows for your organization.

Policy task

A separate task is created and assigned to each unique Managed By Group value within the set of target CIs in a policy. A policy task triggers the policy subflow, tracks the set of target CIs for the task, and handles the approval of the task, if necessary.

If a policy requires an approval, the policy tasks don’t trigger the policy subflow until a member of the group assignment in the Managed by Group attribute of the target CIs, approves the tasks. If a task is rejected or if the Managed by Group attribute is empty, the task is assigned to an administrator who must manually intervene to resolve the task.

If a policy isn't configured to require an approval, then the policy tasks are automatically approved.

CI exclusion list
A set of CIs to which policies of a specified type don't apply.

Policy types

You can create policies of the following types:
Delete
Use to remove a CI from its current table with no option to restore the CI into an active state.
Retire
Use to retire a CI while keeping the CI active in list views and in processes such as CMDB Health.
Attestation
Use to assign and process attestation tasks that verify the existence of actual IT infrastructure and applications that you own. As CIs are continuously ingested into the CMDB from various data sources, attesting CIs support the integrity of the CMDB. For more information about using the Attestation policy type, see CIs attestation.
Archive
Use to remove a CI from its current table and store the CI in a separate archive table for temporary retention. Archiving a CI excludes the CI from views and from features such as maps and the relations formatter. During the retention period, you can restore CIs into active state. At the end of the retention period, archived CIs are deleted from their archive table.
Delete CMDB Related Entry

Use to clean up any irrelevant or stale data from related tables to help keep CMDB data healthy and relevant as the state of referenced CIs change.

Related tables, such as the Serial Number [cmdb_serial_number] table, aren't part of the CMDB hierarchy but still qualify as CMDB data. Related tables don't inherent from the Configuration Item [cmdb_ci] table, but have at least one column that references a CMDB CI. Related tables are specified in the Related Entries [cmdb_related_entry] table.

Certification
Use to certify that specific attributes are of a specific value.

You can implement your Retire, Delete, and Archive policies so that they follow Common Service Data Model (CSDM) standards where for example, CIs are archived and deleted only when a CI is already in retired state. When you create these life-cycle policies, the system applies processes to manage any dependent CIs that might be left behind. For more details about these processes and about verifying that the feature is enabled, see Dependent CIs management.

ServiceNow AI Platform® data archiving

The functionality that the Archive policy type in CMDB Data Manager provides, relies and extends the ServiceNow AI Platform® data archiving feature, applied specifically for CMDB CIs. While processing an Archive policy to archive CMDB CIs, CMDB Data Manager uses components and processes of ServiceNow AI Platform® data archiving in the following ways:
  • The Archive Rule [sys_archive] table contains the ServiceNow AI Platform® archive rules including the Archive Configuration Items CMDB archive rule which CMDB Data Manager Archive policies use.
  • Data Manager relies on the Archive scheduled job to run (every hour by default) and process CMDB Data Manager archive policies. The Archive scheduled job is stored in the Schedule Item [sys_trigger] table.
  • In the ServiceNow AI Platform® table Archive Job Execution Chunks [sys_archive_run_chunk], the Keys attribute contains the sys_ids of the CMDB CIs to be archived (where Rule ID is the CMDB archive rule ID).

  • Archived records are stored in the ServiceNow AI Platform® archive tables, which are prefixed by 'ar_'. In a similar way, the first time that a CMDB archive job runs, it creates an archive table for each CMDB class (prefixed by 'ar_cmdb'). The initial CMDB archive task, therefore, takes longer than subsequent CMDB archive tasks.

    For each Data Manager archive policy, the system batches the policy CIs to be archived into batches of 1000 CIs. The sys_archive_run_chunk table contains a record for each of the batches.

    CMDB archive tables, such as ar_cmdb_ci_computer, are listed under All > System Archiving > Archive Tables.

When using the CMDB Data Manager to archive CIs, you can also directly apply ServiceNow AI Platform® data archiving features, such as restore CIs into active state during a CIs retention period.

CI life cycle management

You can use life-cycle policies in CMDB Data Manager to manage the life cycle of CIs. Those life-cycle policies use retirement definitions that specify the retirement state for classes in your organization and support the transition of CIs through life cycle stages. For more information about accessing and managing retirement definitions, see Retirement definitions.

In general, CIs that are no longer needed should be retired. Then, to complete the CI life-cycle, retired CIs should be deleted or archived according to business needs. The following high level steps describe how to manage CIs' life cycle:
  1. Use a non-production instance as a safe environment for configuring and testing life-cycle management in your organization.
  2. Choose the CI class for which you want to define a retirement definition while carefully considering derivation. Due to derivation, the retirement definition that you are specifying for a class, is also in effect for all child classes that don’t have their own retirement definition.
  3. Specify the retirement definition for the class.
  4. Create a retirement policy targeting the CIs that you want to retire.
  5. Create a delete or an archive policy targeting the retired CIs.
  6. After testing and verification that the entire life-cycle management plan works as intended, transfer all of those configurations to the production instance.
The life cycle state of a CI affects the CIs visibility and inclusion in ongoing CMDB processes:
  • A retired CI isn't excluded from any views or processes such as CMDB Health.
  • An archived CI no longer exists in its active table and instead it's stored in a separate archive table. Archived CIs are no longer visible or included in processes such as list views, maps, and relations formatters. Archived CIs can be retained for a specified retention period before being deleted from the archive table. During the retention period, archived CIs can be manually restored into an active state by using the ServiceNow AI Platform® feature to restore CIs into active state.
Note: Deleting a CI is an irreversible operation. A deleted CI no longer exists in the table that it belonged to and there's no way to restore it to an active state.

Configure the environment for CMDB Data Manager

Prepare your environment for using the CMDB Data Manager:
  1. Some policy types such as the life-cycle policies Retire, Archive, and Delete, require that an active retirement definition exists for each targeted class in the policy. This requirement doesn't apply to all policy types. For example, this requirement doesn't apply to the Attestation policy type. If you attempt to create a policy of a policy type for which this requirement applies but isn't met, an error message appears and the operation fails.
  2. You can streamline approval of policies by populating the Manage by Group attribute of CIs that you plan to target in policies. Use the CI Class Manager to populate that attribute for an entire class, in a single synchronization operation. For more information about this data synchronization, see Set the group for a CI or an entire class of CIs. If the Managed by Group attribute isn't populated for a CI, then the approval process is directed to the administrator.