Article: Beyond the Basics - 7 CMDB Levers Most ServiceNow Developers Never Touch

[Vikram Reddy]

Beyond the Basics: 7 CMDB Levers Most ServiceNow Developers Never Touch

Stop writing custom scripts for problems the platform already solved.

Author: Vikram Karety  Read time: 10 minutes 

Let's be honest. If you have worked on a ServiceNow CMDB for more than a year, you have probably written the same five scripts more than once.

A REST endpoint that bypasses IRE because it was faster. A scheduled job that retires CIs by sys_class_name because nobody told you Data Manager exists. A workspace tile that hides duplicates behind a clever filter. A copy of install_status into a custom field because the new CSDM lifecycle felt scary at 2am.

Here is the part nobody says out loud: the platform already handles most of that. It has for several releases. The features just live in places that almost nobody clicks.

This article runs through seven CMDB capabilities that get overlooked on almost every project I review. None of them are obscure. None are paid add-ons. Each one will cut your custom code, calm your CMDB Health Dashboard, and give you something solid to point at in your next architecture review.

Skim it, pick one or two for the project you are working on right now, and drop the ones you have used in the comments.

 

1. The Identification Engine API for scoped applications

What it is

sn_cmdb.IdentificationEngine.createOrUpdateCI() is the supported way to push a CI payload into the CMDB from a scoped app. It runs your identification rules, your reconciliation rules, your transformation rules, and only then writes to the target class. Same path Discovery uses. No shortcuts.

Why it gets missed

First instinct in a scoped app is to run a GlideRecord insert against cmdb_ci_server and call it a day. That works. It also skips every check the CMDB has for duplicates, source priority, and rule violations. The global-scope IRE is well known. The scoped version lives behind the plugin com.snc.cmdb.scoped (Configuration Management For Scoped Apps CMDB), and plenty of teams have never activated it.

How to use it

javascript

// Inside a scoped application
var payload = {
    "items": [{
        "className": "cmdb_ci_linux_server",
        "values": {
            "name": "lnx-prd-app01",
            "serial_number": "SN-9F12-AB44",
            "ip_address": "10.20.30.40",
            "fqdn": "lnx-prd-app01.example.com"
        }
    }]
};

var sourceName = "MyApp_Inventory_API";
var output = sn_cmdb.IdentificationEngine.createOrUpdateCI(
    sourceName,
    JSON.stringify(payload)
);

gs.info('IRE response: ' + output);

The response tells you whether the CI was inserted or updated, the sysId, and which identifier matched. If you have built any custom intake (Slack bot, third-party agent, in-house CLI), this single API saves you from rebuilding duplicate detection from scratch.

Gotcha: Activate com.snc.cmdb.scoped first and make sure sn_cmdb is writable cross-scope. Confirm the identification rule for the target class lists every attribute you are sending. Missing a required identifier returns Required_Attribute_Empty and IRE refuses the write. That is the engine doing its job.

 

2. CMDB 360 and Multisource CMDB

What it is

CMDB 360 (the artist formerly known as Multisource CMDB) tracks every CI attribute by source. For each writable field, it logs which discovery source proposed which value, when, and which value is currently winning. You can roll back a single attribute to a previous source or recompute everything when reconciliation rules change.

Why it gets missed

It is hidden behind a system property and most projects never turn it on. Without it, the CMDB stores one value per attribute and overwrites silently when a different source wins. With it, you get a per-attribute audit trail that pays for itself the first time someone asks who changed the IP on this server last Tuesday.

How to use it

Flip the switch:

glide.identification_engine.multisource_cmdb_ci_enabled = true

Check cmdb_multisource_data for the per-attribute, per-source history. CMDB Workspace gives you a clean CMDB 360 view on top of it.

Real-world payoff: your asset management feed and your network monitoring feed disagree about operational_status every night. Without CMDB 360, you see the fight only when ops complains. With CMDB 360, you can open the CI, see both proposed values side by side, and fix it by updating reconciliation priority instead of writing yet another patch script.

Gotcha: It costs storage. Lineage per attribute grows the underlying table. Exclude classes you do not need history for, enable it in non-prod first, and watch the table grow for a week before flipping it on in production.

3. The Common Connection Framework (CCF) for Service Graph Connectors

What it is

CCF is the standard pattern every modern Service Graph Connector ships on. It has three stages, Extract, Transform, Load, each with pluggable Script Includes and OOB activities. Data lands in u_ccf_staging_* tables and gets pushed into the CMDB through IRE. There is also a central console called SGC Central inside CMDB Workspace where you can see connector health, run history, and version status in one place.

Why it gets missed

Teams keep building custom REST imports every time a new data source needs to populate the CMDB. Works in week one. Falls over by month six when an admin changes a credential, the source adds a field, or the receiving CI class gets a new identifier. CCF is the same idea, but pre-built, upgrade safe, and observable from one screen. The reason it gets missed is pure awareness. Until you ship one connector with it, you assume real integrations need IntegrationHub flows and a pile of transform maps.

How to use it

Browse the connector store under SGC Central. If a connector already exists for your source (Azure, AWS, SCCM, Tanium, Terraform, and the list keeps growing), install it. If not, roll your own:

• Extract: REST step or scheduled JDBC pull
• Transform: a Script Include that returns clean JSON aligned to the target CI classes
• Load: write to u_ccf_staging_<your_connector> and configure an IRE-driven Robust Transform Map

The win is consistency. Every connector you build this way is observable, upgrade tested, and reusable by another team.

Gotcha: CCF expects you to think in payloads, not records. The moment your transform stage writes directly to cmdb_ci_*, you have built a custom integration and lost the framework's benefits. Resist the temptation to speed things up by skipping the staging table.

 

4. CMDB Data Manager policies for cascade lifecycle

What it is

CMDB Data Manager lets you define policies (Retire, Archive, Delete) that act on CIs based on a condition, then cascade those actions through dependent CIs using your relationship rules. Three OOB policies (Dependent CI - Retire, Dependent CI - Archive, Dependent CI - Deletion) handle the downstream children for you.

Why it gets missed

Almost every CMDB I open has a hand-rolled script looping through CIs by class to retire them. Those scripts age badly, ignore relationships, and break when the schema changes. Data Manager treats lifecycle as a policy, not a script. Cleaner. Easier to defend in a peer review.

How to use it

Build your policy in the CMDB Data Manager workspace:

• Trigger condition (last_discovered older than 90 days, install_status of on order, etc.)
• Action (Retire, Archive, Delete)
• Confirm the dependent CI relationship rules (Depends on, Hosted on) so the cascade engine knows how to walk the graph
• Optional: attach a subflow for custom approval logic before the cascade fires

Under the hood two scheduled jobs do the work. CMDB Cascade Retire Dependent CIs populates a ledger of downstream CIs that need action. CMDB Data Manager Retire Policy Processor processes the ledger in batches. You can watch it fill up and drain in real time, which is oddly satisfying.

Gotcha: Cascade only follows relationship rules explicitly defined as dependent. If your custom relationship type does not have a dependency rule on cmdb_rel_type, the cascade silently skips those children. Always validate your dependency rules before you blame the policy.

 

5. ATF (Automated Test Framework) for CMDB

What it is

The com.snc.cmdb.atf plugin ships with 18 OOB tests for CMDB health, including identification, reconciliation, duplicate detection, orphan rules, and Health Dashboard computation. You can extend them with custom steps to cover your own business rules.

Why it gets missed

ATF mostly gets used for ITSM forms. CMDB testing usually means running Discovery and squinting at the dashboard. Fine, until an upgrade quietly changes a Health computation, or a plugin update tweaks an OOB identifier, and you only find out three weeks later when a regulator's report fails. ATF for CMDB catches that on day one.

How to use it

Install the plugin. Open Automated Test Framework > Tests and filter by the CMDB category. Pick five to start with that match your top risks:

• IRE creates a new CI when no identifier matches
• IRE updates an existing CI when an identifier matches
• A duplicate triggers the duplicate alert
• An orphan rule fires when a CI loses its parent
• The Health Dashboard computes correctness within expected ranges

Schedule them after every CMDB-touching deployment in your CI/CD pipeline. When something breaks, ATF tells you in minutes, not weeks.

Gotcha: ATF needs glide.atf.tests.enabled = true and an admin with atf_test_admin to run. Make sure your test runner has CMDB read/write access. Otherwise tests fail with permission errors that look exactly like data issues, which is a fun way to waste an afternoon.

 

6. CSDM Lifecycle Stages and the migration from install_status

What it is

CSDM 4.0 introduced a two-tier lifecycle (life_cycle_stage and life_cycle_stage_status) that replaces the legacy install_status and operational_status. The new model is consistent across CI classes, supports formal transitions, and is what ServiceNow products are increasingly built around.

Why it gets missed

This one does not get missed because it is unknown. It gets missed because everyone is terrified of it. install_status is referenced in thousands of business rules, reports, and assignment rules across most mature instances. Migrating feels like brain surgery on a sleeping patient.

How to use it

The platform actually gives you a guided path:

• Activate the lifecycle plugin and use the Enable Lifecycle Stages button. This migrates legacy values to the new fields based on predefined mappings.
• The scheduled job CI Lifecycle Management - Restore Internal State Management Tables scans regularly and resyncs any CIs that drift.
• Use LifeCycleUtil as your API gate before any custom job touches lifecycle fields.

javascript

var lifeCycleUtil = new LifeCycleUtil();
if (!lifeCycleUtil.isLifeCycleMigrationActivated()) {
    gs.warn('Lifecycle migration not activated. Aborting.');
} else if (lifeCycleUtil.isBulkPopulationActive()) {
    gs.warn('Bulk lifecycle population already running. Skipping this cycle.');
} else {
    // Safe to operate on lifecycle fields
}

Gotcha: Activating lifecycle on a production instance with linked hardware assets can flip asset state to Consumed unexpectedly (there is a published KB on this). Test in non-prod, validate the asset state mapping, and freeze any custom asset workflows that read state during the migration window.

 

7. IRE debug tools: Payload Navigator and background script debugging

What it is

Two tools that turn IRE from a black box into a glass box.

First, IRE debug logging. Set com.snc.cmdb.ire.debug = true and IRE writes verbose entries to System Logs for every payload: which identifier was attempted, why a match did or did not happen, which reconciliation rule chose the winning value.

Second, the ITOM Payload Navigator. A Community-distributed tool (unsupported, so non-prod only) that takes an ECC Queue payload or raw JSON/XML and renders it as a navigable graph. URL: https://<your-instance>.service-now.com/payloadNavigator.do

Why they get missed

When a CI does not match, the default move is read the logs, give up, post on the Community. Both of these tools answer the question directly. They are not advertised because they are diagnostic, but they should be in every CMDB developer's first-week toolkit.

How to use background script debugging

Drop the payload into a background script and run identification on demand:

javascript

var jsonInput = {
    "items": [{
        "className": "cmdb_ci_linux_server",
        "values": {
            "name": "lnx-prd-app01",
            "serial_number": "SN-9F12-AB44"
        }
    }]
};

var output = SNC.IdentificationEngine.createOrUpdateCI(
    "Manual_Debug_Vikram",
    JSON.stringify(jsonInput)
);

gs.info(output);

The output JSON tells you exactly which identifier was attempted, what matched, and what IRE did. Pair this with the debug logs and roughly 90 percent of why-won't-my-CI-match tickets disappear.

Gotcha: Use a unique sourceName like Manual_Debug_<your-name>. Otherwise your tests leave fake source records on the CI that confuse the next person to look at it. Clean up after yourself, future-you will appreciate it.

 

How to start using these on your current project

You do not need a full CMDB transformation program to put these to work. Pick the two that match where you are right now:

• Building integrations: start with CCF (Lever 3) and the Identification Engine API (Lever 1).
• Inheriting a noisy CMDB: turn on CMDB 360 (Lever 2), then put Data Manager (Lever 4) to work.
• Heading into an upgrade: install ATF for CMDB (Lever 5) before you go anywhere near the upgrade plan.
• Running CSDM 4.0 or later: validate your lifecycle migration (Lever 6) in non-prod this sprint.
• Drowning in IRE tickets: enable IRE debug logs and Payload Navigator (Lever 7) this week.

Each one is a small investment that pays back across every future CMDB change.

---

Closing thought

The CMDB has quietly become one of the most capable parts of the ServiceNow platform. The skill that separates a senior CMDB developer from a junior one is no longer scripting. It is knowing which platform capability already does the job and using it instead of writing custom code.

If this saved you time, mark the article as helpful so the next developer searching for the same answers finds it. If I missed a lever you swear by, drop it in the comments. I will compile the best ones into a follow-up post.

Happy building.

Thank you,

Vikram Karety

ServiceNow Architect

Octigo Solutions INC

#CMDB #IRE #CSDM #CMDB360 #ServiceGraph #ATF #CMDBDataManager #ServiceNowDeveloper #ITOM

[Mark Manders]

You state "None are paid add-ons." CMDB 360 requires ITOM Discovery license.