A Service Graph Connector Is a Standard CMDB Integration Underneath

Both certify on the Store and share the same core, the Identification and Reconciliation Engine (IRE). Choose the Service Graph Connector (SGC) program when its category and what ServiceNow’s program data sheet calls “better sales alignment” 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.

Consider a ServiceNow integration that writes to the Configuration Management Database (CMDB). In our experience, most teams building one treat “Service Graph Connector” and “standard CMDB integration” as two different things to build. They aren’t.

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 taken 25+ apps through ServiceNow Store certification, we get asked about that part most. The Service Graph Connector program is the stronger choice for the right product. This page 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. That foundation is the “standard CMDB integration,” of which an SGC is a superset:

• It writes through IRE. You don’t insert into CMDB tables directly—IRE handles identification, de-duplication, and reconciliation so the same configuration item (CI) isn’t created twice.
• It maps incoming data to CMDB classes through a staging table (an import set that applies IRE), rather than leaving it 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. In our experience, review expects a support page and a Contact Support module (one of ServiceNow’s ten most-failed checks), scheduled imports shipped inactive, no packaged credentials and clean packaging; apps that write CIs go through IRE.

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. The app is listed as a Service Graph Connector rather than as a standard integration.
• 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. In our experience, ServiceNow still asks for validation with two ServiceNow customers before release.
• Alignment with IT Operations Management (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.
• Sales alignment and support. ServiceNow’s program data sheet (June 2020) lists “Better sales alignment” and “Enhanced customer support” among its benefits for partners.

Take a connector whose customers run ITOM and who benefit from the branded category and the sales alignment ServiceNow describes. For that connector, the 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 sales alignment ServiceNow describes, 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.

Conversion comes up when a connector starts life as an SGC and the standard path later fits better. The positioning may shift, or the ITOM framing may no longer match 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. In that case, keep only the dependencies you 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, with its own certification and listing. 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. 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.

In our experience, these are quick to settle, and confirming them up front keeps the resubmission smooth.

Is a Service Graph Connector better than a standard CMDB integration?

No. 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.

Questions

What is a Service Graph Connector?

A Service Graph Connector is a certified ServiceNow Store integration that populates the CMDB from a third-party source through the Identification and Reconciliation Engine (IRE). Technically it’s a standard CMDB integration. The “Service Graph Connector” name marks a ServiceNow program layer on top—a branded Store category, a design review, and ITOM licensing alignment.

Do I have to be a Service Graph Connector to write to the CMDB?

No. Any certified Store app can populate the CMDB through IRE. The Service Graph Connector program adds a branded category and a review process on top of that. It isn’t a technical prerequisite for writing to the CMDB. A standard CMDB integration is still fully certified and populates the CMDB correctly.

What’s the biggest time-sink on the Service Graph Connector path?

In our experience, ServiceNow still asks for validation with two ServiceNow customers, and that step is the long pole. You need two customers willing to run the connector, stand up an instance to test it on, and get their source system syncing into it. On their schedule, not yours.

Will a standard CMDB integration still pass Store certification?

Yes. In our experience, review expects a support page and a Contact Support module, scheduled imports shipped inactive, no packaged credentials and clean packaging. It also expects apps that write CIs to go through IRE. A standard CMDB integration meets all of that without the SGC-specific program steps.

Does dropping the Service Graph Connector label cost you anything?

It does, and it’s worth weighing honestly. You give up the “Service Graph Connector” category, and the sales alignment ServiceNow says comes with the program. If those are central to how you reach buyers, the program earns its keep. If they aren’t, a standard integration gets you a certified listing with less overhead.

Is converting risky for customers already running the connector?

The integration keeps working, but renaming the discovery source is a breaking change for instances that already ingested data under the old name. Existing CIs keep the old value. With live customers, plan a migration or a version bump rather than a silent rename. With no installs yet, it’s a clean change.

Can I move from a standard integration to a Service Graph Connector later?

Yes. Because the SGC program builds on the same CMDB foundation, a standard integration can go through the program later. Do it if your product grows into ITOM and the branded category becomes worth it. It isn’t a one-way door.