Every Service Graph Connector Is a Standard CMDB Integration Underneath

A Service Graph Connector is a standard CMDB integration plus a ServiceNow program layer—a branded Store category, a design review, and ITOM alignment. Both certify on the Store and share the same IRE core. Choose the program when its category and co-sell matter to your go-to-market; otherwise a standard integration gets you there faster. Moving between the two is a contained change, not a rebuild.

Most teams building a ServiceNow integration that writes to the CMDB treat “Service Graph Connector” and “standard CMDB integration” as two different things to build. They aren’t. A Service Graph Connector (SGC) is a standard CMDB integration with a program layer on top—the same IRE-based core, plus a branded Store category, a design review, and ITOM alignment. ServiceNow documents how to build a Service Graph Connector thoroughly; what’s less written down is how the two paths relate, and what it takes to move between them. Having certified 25+ apps for the ServiceNow Store, across both Service Graph Connectors and standard CMDB integrations, that’s the part we get asked about most. The Service Graph Connector program is the stronger choice for the right product—this is about picking the path that fits yours, and knowing your options if that fit changes.

What do a Service Graph Connector and a standard CMDB integration share?

Everything technical. Whether or not you join the SGC program, an integration that writes to the CMDB rests on the same foundation—the “standard CMDB integration,” of which an SGC is a superset:

• It writes through the Identification and Reconciliation Engine (IRE). You don’t insert into CMDB tables directly—IRE handles identification, de-duplication, and reconciliation so the same CI isn’t created twice.
• It maps with IntegrationHub ETL, which uses the Robust Transform Engine (RTE). Incoming payloads land in a staging table, then get transformed and mapped to the correct CMDB classes rather than left in a flat table.
• It registers a discovery source. Every CI it creates is stamped with a discovery source so customers can see where the data came from.
• It respects the CMDB schema. No new columns on CMDB tables and no new tables inside the CMDB; external identifiers live in the CMDB’s key-value store (cmdb_key_value), and anything genuinely custom lives in the app’s own scope.
• It meets the Store’s certification baseline. A support page and support module, scheduled imports shipped inactive, no default credentials packaged, and clean packaging are expected of any app on the Store.

Get these right and you have a solid, certifiable CMDB integration—SGC or not.

What does the Service Graph Connector program add?

A certified, branded, and supported layer on top of that shared core. From ServiceNow’s public program materials and our own work, it includes:

• A recognised Store category. “Service Graph Connector” is a category customers actively browse when they’re looking for a trusted way to feed their CMDB. That discoverability is real.
• A design review with ServiceNow. Your data model and mapping approach are reviewed before you go far—a quality checkpoint that helps you avoid rework and signals rigour to customers.
• Validation with ServiceNow customers. Connectors are proven with real customers before they’re broadly listed.
• Alignment with ITOM licensing. SGCs are positioned alongside ITOM Visibility and ITOM Discovery, and the listing is explicit about how the connector interacts with that licensing model.
• Naming and navigation conventions. SGCs follow a consistent naming pattern (the distinctive SG- prefix on discovery and data sources) and a standard place in the navigator, so every connector feels familiar to customers.
• Program support and co-sell alignment. Membership comes with a closer relationship to ServiceNow around support and go-to-market.

For a connector whose customers run ITOM and who benefit from the branded category and co-sell, that package is worth what the program asks of you.

When should you choose a Service Graph Connector vs a standard CMDB integration?

Choose a Service Graph Connector when the branded category, the co-sell relationship, and ITOM alignment are central to how you reach customers; choose a standard CMDB integration when they aren’t. Both are fully certified and populate the CMDB through the same IRE core, so it’s a go-to-market decision, not a technical one.

A standard CMDB integration is still fully certified and populates the CMDB correctly—it simply isn’t part of the SGC program.

How do you convert a Service Graph Connector to a standard CMDB integration?

Converting is mostly removing and relabeling the program-specific layer—not rebuilding the integration. Because an SGC is a superset of a standard integration, the IRE-based core keeps working, and it’s five steps. It comes up when a connector starts life as an SGC and the standard path later fits better—the positioning shifts, or the ITOM framing no longer matches how it’s sold. (Adopting an SGC is well documented by ServiceNow; moving the other way isn’t, so that’s the direction we cover.)

1. Drop the SG- naming and re-register the discovery source.
2. Give the app its own navigation.
3. Review your dependencies and listing.
4. Keep the CMDB baseline intact.
5. Re-test and resubmit for Store certification.

Here’s each step in detail.

1. Drop the SG- naming and re-register the discovery source. The SG- prefix is the most visible convention of an SGC, so a standard integration shouldn’t use it. Rename the discovery source, the data sources, and the scheduled imports to remove it, then update anything that references the old discovery-source value—your registration fix script and any ETL mappings or load logic. The registration itself is a standard call:

var dsUtil = new global.CMDBDataSourceUtil();
dsUtil.addDataSource("MySource"); // MySource = your discovery source name (often your product name)

2. Give it its own navigation. Move the app out of the Service Graph Connectors navigation group and give it its own application menu.

3. Review your dependencies and listing. If your integration doesn’t itself require ITOM Visibility or Discovery, you can remove ITOM licensing dependencies and the associated Subscription-Unit note, and keep only the dependencies you actually use (Integration Commons for CMDB, the CMDB CI Class Models, and IntegrationHub ETL if you use ETL). Confirm the licensing posture that’s right for your app with ServiceNow—more on that below. Update the Store listing so it no longer presents the app as a Service Graph Connector.

4. Keep the CMDB baseline intact. Everything from the shared-core section still applies: insert through IRE, don’t change the CMDB schema, keep the support page and packaging hygiene. This is what keeps the app certifiable.

5. Re-test and resubmit. Re-run an end-to-end import, confirm IRE identification and the new discovery-source stamping behave as expected, then resubmit the app for Store certification.

Two things to plan for:

• Your scope name. If the scope technical name reads as “Service Graph,” changing it means a new scope—effectively a new app that occupies another of your certification slots. If the scope name is neutral, keep it and just relabel the app.
• Existing installations. Renaming the discovery source is a breaking change for any instance that already ingested data under the old name—existing CIs keep the old value. With live customers, plan a migration or version bump rather than a silent rename.

For what the certification team actually inspects, and the realistic timeline, see our ServiceNow app certification guide—and once an app is listed, keeping it there means recertifying with each new ServiceNow release.

What should you confirm with ServiceNow before converting?

Moving a connector between programs is situational, and ServiceNow’s certification team is the authority on it. Before you resubmit, confirm four points with your ServiceNow contact so you proceed exactly the way they’d prefer:

• Licensing: whether removing the ITOM dependencies and the Subscription-Unit note is right for your specific integration.
• Source Native Key: whether your connector’s key needs any change when it moves off the program, or simply carries over.
• Scope name: whether an existing scope that reads as “Service Graph” can stay, or whether they’d prefer a new one.
• Transition mechanism: how they’d like the existing listing re-categorised—an in-place update or a new application record.

These are quick to settle, and confirming them up front keeps the resubmission smooth.

The bottom line

Service Graph Connector and standard CMDB integration aren’t better-or-worse—they’re two well-supported ways to put third-party data into the CMDB, and they share the same technical core. The SGC program adds a branded category, a design review, customer validation, and ITOM alignment that are exactly right for some products. A standard CMDB integration is the right fit for others. Choose on purpose—and know that if your product’s needs change, moving between them is a contained, well-understood piece of work.

Part of our ServiceNow app certification guide — what the review checks, the real timeline, and what apps fail on.