Troubleshooting ServiceNow Common Service Data Model: A Practical Guide

This guide helps a platform administrator work out why records in the Common Service Data Model are missing, duplicated, out of date or disconnected, and where in the chain the fault begins. Each symptom has its likely root causes and a fix, and a backwards trace covers one wrong record.

Symptom: Missing or Orphaned CSDM Records

Diagnosis: Some records that should be in the Common Service Data Model are not appearing. For example, applications are created in the application table but do not appear in the service graph. Or business services are defined but their child applications are missing.

Root causes: Reconciliation is not running or has failed, data mapping between source and CSDM tables is incorrect, or records fail validation and are skipped during import.

Fix: Check if reconciliation jobs are scheduled and running. Review reconciliation logs for errors or warnings. Verify data mapping: do the source system fields map correctly to CSDM tables? Run a manual reconciliation on a small subset of records and verify results. If mapping is incorrect, fix the mapping and re-run reconciliation.

Symptom: Service Relationship Graph Is Broken or Incomplete

Diagnosis: Services are defined, but their relationships to applications, infrastructure, and business services are not visible. The service graph shows disconnected islands instead of an integrated view.

Root causes: Relationship tables are not populated, relationship mapping is incorrect, or the graph rendering is not configured.

Fix: Check the CI relationship table (cmdb_rel_ci) for missing relationships. Verify that relationships are being created during reconciliation. If relationship mapping is missing, add it. Test by creating a manual relationship and verifying it appears in the service graph. If the graph does not render relationships, check graph configuration and permissions.

Symptom: Data Duplication in CSDM

Diagnosis: The same service or application appears multiple times in CSDM with different record IDs. This causes confusion in reporting and can lead to incomplete incident impact analysis.

Root causes: Reconciliation creates duplicate records if source systems have duplicate entries, deduplication rules are not configured, or manual entries are not reconciled with automated entries.

Fix: Clean source data first: remove duplicates in the source system (CMDB, discovery, HR system). Configure deduplication rules in reconciliation to identify and merge duplicate CSDM records. Use the CSDM merge workflow to consolidate duplicates into a single canonical record.

Symptom: Reconciliation Lag Between Source and CSDM

Diagnosis: A new application is added to the source system, but it does not appear in CSDM for hours or days. Change requests are made, but CSDM lags behind.

Root causes: Reconciliation is scheduled infrequently (daily or weekly instead of hourly), reconciliation jobs are slow or timing out, or reconciliation queue is overloaded.

Fix: Increase reconciliation frequency: run reconciliation hourly or continuously for critical data. Optimise reconciliation queries to run faster. If queue is overloaded, add more reconciliation workers. Monitor reconciliation performance and adjust based on lag metrics.

Symptom: CSDM Data Quality Issues

Diagnosis: CSDM records have missing or incorrect data: null values in critical fields, inconsistent naming conventions, or incorrect classification of services.

Root causes: Source data quality is poor, mapping does not handle null values or data transformation errors, or validation rules are not strict enough.

Fix: Audit source data quality: identify records with missing critical fields and correct them at the source. Review data mapping: add default values for missing data, add data transformation logic to standardise naming. Implement validation rules: reject or quarantine records that fail validation and alert data owners to fix them.

Symptom: Impact Analysis Inaccuracy

Diagnosis: When an incident is created for an infrastructure component, impact analysis does not show the correct affected services and applications. The business impact is not accurately calculated.

Root causes: Service relationships are incomplete or incorrect, business impact logic is not configured correctly, or impact mapping rules are missing.

Fix: Verify service relationships: trace from infrastructure through applications to business services. Check impact configuration: does it correctly traverse the relationship graph? Test impact analysis with known scenarios: when this server goes down, these services should be affected. Verify the actual result matches expectations. If not, adjust relationships or impact logic.

Symptom: Reconciliation Failures and Warnings

Diagnosis: Reconciliation logs show numerous errors or warnings: “record failed validation”, “lookup failed”, “relationship could not be created”.

Root causes: Source data has invalid or missing values, lookup tables are incomplete or misconfigured, or schema changes broke the reconciliation.

Fix: Review errors in detail: which records fail and why? Fix source data to correct errors. If lookups fail, populate the lookup table or adjust lookup criteria. If schema changes occurred (new fields, table renames), update reconciliation mapping accordingly. Re-run reconciliation and verify error rate drops.

Symptom: Performance Degradation After CSDM Activation

Diagnosis: After CSDM is enabled, incident and change management workflows are slower, or searches are taking longer.

Root causes: Large CSDM data sets consume memory and CPU, impact analysis is computationally expensive, or indexes are missing.

Fix: Profile slow queries to identify bottlenecks. Add database indexes on frequently queried fields. Optimise impact analysis queries. Consider caching impact calculations if they are expensive. Monitor database performance and add resources if needed.

Tracing one wrong record back to where it came from

A single bad entry in the service model is rarely a random event. It is the end of a chain: a discovery pattern wrote an attribute, a reconciliation rule decided which record won, a manual edit overwrote a field, or a relationship was created against the wrong type of item. Fixing the visible record without finding the link that produced it can let the same error appear again next cycle. This section gives a backwards-tracing method for one wrong record. It is for the platform administrator or service data analyst who has been handed a complaint about a single service and needs to find out whether the fault is local or systemic.

The method works best when you choose the record that someone actually noticed, such as a business application showing the wrong owner or a service with an impact link that looks absurd. Start from the symptom in the record and move upstream one link at a time. Keep a note of each field value and the time it last changed, since that timeline is often what separates a source-system fault from a configuration fault. For the wider picture of how these records get created and kept accurate, the general CMDB troubleshooting guide covers the surrounding mechanics.

Where the fault often sits, by field

A backwards trace in six steps

1. Write down the record identifier, the field in question, the value you see and the value you expect, with a one-line reason for the expectation.
2. Open the audit trail for that field. Note who or what changed it, when, and whether the change was a load or a manual edit.
3. If a load changed it, identify the source and the mapping that carried the value across. Check whether the mapping was edited recently.
4. If a manual edit changed it, ask the editor why, and whether the same edit could recur through a form, an import or an automation.
5. Check the relationships on the record. A wrong parent or a missing dependency often points to the rule that created the relationship, so note the rule name and the date it was last changed.
6. Test the suspected cause on a copy or a single record. Confirm the wrong result reproduces, then confirm the fixed mapping or rule gives the right result, before changing production data.

When to fix the record and when to fix the rule

Correcting the single record is the right first move when the fault is isolated and the source is correct. Changing a rule to fix one record is the wrong move, because the rule will then behave differently for every other record it touches. Move to the rule when the same wrong value appears on several records that share a source, a region or a service owner, or when the rule’s last change lines up with the first bad record. Keep the correction and the rule change in the same change record, so the audit trail shows that the cause was addressed rather than masked.

What a clean trace looks like at the end

A useful trace ends with three things written down: the mechanism that produced the wrong value, the set of other records that share that mechanism, and the one change that stops it recurring. If you finish with only the corrected record, the investigation has not finished. A good test is whether another administrator, reading your note a month later, could find the same source without asking you.

Why does the wrong value come back after I correct it?

Often because the source still holds the old value and the next load writes it again. Correct the source, or exclude that field from the load for that source, rather than repeating the manual edit each cycle.

How do I tell a duplicate from two genuinely separate items?

Compare the identifiers each copy was created with and the sources that created them. Separate items often differ in a stable identifier such as a serial or a unique name, while duplicates share the identifier but arrived through different loads. Merge only after both copies have been checked against the source.

Should I rerun a load to see whether the fault clears?

Only on a test copy, or after you know which record the rerun will touch. A full reload can overwrite manual corrections made since the last load, which can turn a small fault into a larger one.

Who should be told when the fault turns out to be systemic?

The owner of the mapping or rule and the owner of the business service affected, in that order. The rule owner can confirm the cause, and the service owner can judge how much impact the wrong data has already had on incidents or changes.

Is the audit trail enough to find the cause on its own?

It is the best starting point, but it shows who changed a field, not always why. Pair it with the relationship history and the mapping change log before concluding anything.

Once the trace has identified a rule, the remediation workflow for CMDB records gives a structure for correcting the affected set, and the data quality rules show where a check would have caught the fault earlier. Relationship faults that cross into service dependencies are covered in the guide to service mapping dependencies.