Your organization has a CMDB with 50,000 CIs, but adoption is critically low—only 15% of IT teams actively…

Reading Between the Lines

This isn't a technical failure—it's a data trust failure. Before jumping to solutions, a senior architect must distinguish between three possible root causes: (1) data quality issues (stale, incomplete, inaccurate CIs and relationships), (2) process failures (poor governance, ownership, or reconciliation rules), and (3) usability/adoption failures (teams don't know how to query it or don't see value). The 45-day staleness and incomplete relationships suggest discovery isn't feeding back into the CMDB properly, or identification/reconciliation rules are too loose or too strict.

Diagnostic Approach

Start with data audits, not process changes. Run CMDB health checks on data integrity, reconciliation rule effectiveness, and CI relationship coverage. Check if discovery is actually updating existing CIs (via identification rules) or creating duplicates. Validate whether teams are seeing false positives because relationships are wrong or because the queries themselves are poorly constructed. Interview 3-5 power users to understand what "trust" means to them—is it accuracy, completeness, or speed of updates?

The Solution

// Problem: Discovery creates duplicates, relationships incomplete
// Identification rules too permissive (matches on hostname only)
var gr = new GlideRecord('cmdb_ci_server');
gr.addQuery('name', 'like', 'server%');
gr.query();
// BEFORE: Weak identification rule
// Match on: name, ip_address (allows duplicates if IP changes)
// AFTER: Tiered identification with coalesce
function reconcileCIs(discoveredData) {
  var identificationOrder = [
    'serial_number',      // Primary key
    'mac_address',        // Secondary
    'hostname + domain'   // Tertiary
  ];
  
  // Coalesce field priority in transform map
  var matchedCI = findExistingCI(discoveredData, identificationOrder);
  if (!matchedCI) {
    createNewCI(discoveredData);
  }
  // Relationship sync: validate dependent CIs exist before linking
  syncRelationships(discoveredData, matchedCI);
}

Senior Considerations

• Root cause vs. symptom: Low adoption often masks data quality issues. Don't assume people are lazy; assume they've been burned by bad data before. Rebuild trust incrementally with high-confidence subsets first.
• Identification rules are foundational: Weak rules create duplicates; too-strict rules miss updates. Order matters (serial number > MAC > hostname). Coalesce fields in transform maps prevent slow lookups on large datasets.
• Relationship integrity: Incomplete relationships suggest discovery isn't validating that dependent CIs exist before creating links. This causes orphaned relationships and false impact chains. Implement cascade cleanup policies (cmdb.dependent.ci.cascade.op.enabled) to prevent broken dependencies.
• Data governance ownership: Assign explicit CI class owners and SLAs for update frequency. A discovery tool can't fix governance gaps—it just exposes them faster.
• Phased recovery with trade-offs: Phase 1 (Weeks 1-4): Audit and fix identification/reconciliation rules, deduplicate existing CIs, validate relationship integrity. Phase 2 (Weeks 5-8): Implement data certification process for high-value CI classes (applications, databases). Phase 3 (Weeks 9+): Expand discovery scope and retrain teams on dependency mapping. Cost: a few hundred hours of focused effort; Benefit: adoption can recover substantially within a quarter — but only if data quality demonstrably improves first.
• Avoid common traps: Don't run aggressive deduplication without validation—you'll delete legitimate CIs. Don't over-automate discovery without strong reconciliation rules—you'll create new duplicates. Don't skip the governance conversation—tools alone won't fix trust.
• What makes this great: Acknowledging that low adoption is often a symptom, not the problem. Showing a systematic diagnostic approach (health checks → root cause → phased solution). Demonstrating knowledge of identification rules, coalesce fields, and cascade cleanup. Explaining trade-offs (speed vs. accuracy, automation vs. control). Recognizing that CMDB recovery is 60% governance and 40% technical.