1.2 CMDB Data Manager and Lifecycle Policies

CMDB Data Manager and Lifecycle Policies

As enterprises grow, their Configuration Management Databases (CMDBs) collect vast amounts of data. Over time, virtual servers are decommissioned, software is uninstalled, and devices are replaced. If left unmanaged, this stale data pollutes the CMDB, leading to performance degradation, inaccurate service maps, and inflated licensing costs. To address this, ServiceNow introduced the CMDB Data Manager, a policy-driven framework designed to automate the management of the CI lifecycle.

Before the CMDB Data Manager, administrators relied on custom background scripts, complex business rules, and manual cleanup tasks to prune the CMDB. These legacy methods were difficult to maintain, lacked auditing trails, and often bypassed proper approvals. The CMDB Data Manager replaces these custom solutions with a wizard-driven interface, allowing administrators to define automated lifecycle policies with built-in governance, logging, and approval routing.

1. Native Policy Actions

The CMDB Data Manager supports four primary policy actions, each addressing a specific stage of the configuration item's end-of-life or verification process:

• Retire: This policy action transitions active CIs to a retired status when they are no longer in use. For example, if a virtual machine has not been discovered for 30 days, a Retire policy can automatically update its operational status to "Retired". Retiring CIs first, rather than deleting them immediately, is a best practice that ensures downstream services are not abruptly disrupted.
• Archive: This policy action moves retired CIs out of the active CMDB tables (e.g., cmdb_ci_server) and into archive tables (prefixed with ar_). This keeps the primary database tables thin and performant, while retaining historical configuration details for compliance or audit reviews.
• Delete: This policy action permanently deletes CIs or their archived records. It is typically applied to CIs that have been in a retired or archived state for a set duration (e.g., delete retired virtual machines after 90 days in the archive).
• Attest (Attestation): This policy action is designed for static or non-discoverable CIs (such as office printers, server racks, or manually entered application software). Instead of automating a data change, an Attestation policy generates a manual task for the CI owner, prompting them to log in and verify that the CI still exists, is in the correct location, and has accurate attributes.

Policy Comparison and Default Use Cases

2. Policy Workflow and Task Management

The CMDB Data Manager operates on a structured, asynchronous workflow to ensure safety and compliance before modifying configuration data:

1. Policy Definition: The CMDB administrator defines a policy by selecting the policy type, target CI classes, and filter criteria (using the CMDB Query Builder or standard filter conditions). Key configurations on the policy include Active, Apply to Subclasses (to ensure child tables inherit the rules), and Needs Approval to dictate routing requirements.
2. Evaluation: The scheduled background job CMDB Data Manager - Policy Evaluator runs daily at 12 AM by default. It scans the CMDB for CIs matching active policy criteria.
3. Task Creation: For each matching CI, the engine creates a task record in the CMDB Data Manager Task (cmdb_data_manager_task) table.
4. Approval Routing: The platform routes these tasks to the designated approval groups (such as the CI's Support Group, Managed By Group, or a central CMDB Governance committee). This routing is driven by ServiceNow Flow Designer workflows, which can be customized to match organizational hierarchies.
5. Execution: If a policy is configured for manual execution, the actions are queued until the task is approved and manually closed by the reviewer. If configured for auto-execution, the system automatically applies the database changes (such as updating the status to retired or executing the deletion) as soon as the required approvals are received, or immediately if no approvals are required.

3. Role-Based Access and Governance

To maintain security and prevent unauthorized mass data changes, access to the CMDB Data Manager is strictly controlled via roles:

• cmdb_inst_admin (CMDB Instance Administrator): This role is required to author, modify, and delete CMDB Data Manager policies.
• app_service_admin (Application Service Administrator): This role can manage policies specifically related to application services.
• CI Owners and Support Groups: These users do not need administrative roles; they interact with the system by receiving approvals in their inbox or responding to attestation tasks in the Service Operations Workspace or mobile interface.

It is important to note that when CMDB Data Manager tasks execute automatically, they do so under the context of the system user, leaving a detailed audit trail in the sys_audit table. For manually approved policies, the user who approves the CMDB Data Manager Task is recorded as the execution author, ensuring compliance with strict enterprise audit standards.

By leveraging the CMDB Data Manager, organizations transition from reactive, manual data cleanup to policy-driven lifecycle governance, ensuring the CMDB remains a trustworthy source of truth for the enterprise.