Dynamic CI Group - Actually "Query based service"?

[aasch]

Hi,

I'm currently learning for the new Data Foundations certification.

In several places I've come across "Dynamic CI Group" records.

A few things I am very confused about:

"Dynamic CI Group"s don't seem to add anything at all to the underlying CMDB Group.
The CMDB Group is already the entity that does the "dynamic" (by query) selecting of CIs.
What is supposed to be the dynamic thing about the "Dynamic CI Group" record itself?

The table for Dynamic CI Groups is derived from Service Instance.
For all intents and purposes a Dynamic CI Group seems to actually be a service. The technical table name even is "cmdb_ci_query_based_service".
Why wasn't the table also labelled "Query Based Service" if that's what it actually is, looks like and behaves like?

Do Dynamic CI Groups not "quack like a duck"?

I must assume that I'm missing one or more pieces of the puzzle.
Otherwise I'd conclude that there is a mismatch in labels that causes unnecessary confusion in the already complex CSDM system.

[Pavan Srivastav · Accepted solution]

1. What is actually "dynamic" about a Dynamic CI Group?

You're right that the CMDB Group is already the mechanism doing the dynamic work — it holds the query/filter that selects CIs at runtime. The Dynamic CI Group record itself is essentially a container that points to a CMDB Group and promotes it into the CI hierarchy as a first-class configuration item.

The "dynamic" in the name is meant to contrast it with a Manual CI Group (also called a Static CI Group), where you hand-pick individual CIs into a group with no underlying query. So the distinction is really:

• Manual CI Group → you explicitly enumerate member CIs
• Dynamic CI Group → membership is derived from a saved query via CMDB Group

The word "dynamic" is describing the membership resolution strategy of the group, not any special behavior of the record itself. The record is admittedly just a wrapper. Your frustration is valid — the CMDB Group already carries the dynamic behavior, and the Dynamic CI Group record adds little beyond giving that group a CI identity in the hierarchy.

---

2. Why does cmdb_ci_query_based_service extend Service Instance, and why the naming mismatch?

This is where the historical layering really shows. A few things happened:

Architecturally, it genuinely is a service. When ServiceNow built this out, they needed Dynamic CI Groups to participate in service modeling — dependency mapping, service health, impact analysis. The cleanest way to do that in the CMDB data model was to extend cmdb_ci_service (via Service Instance), because that lineage already had all the relationship hooks, health rollup logic, and dashboarding support built in. Extending a plain CI base class would have meant reinventing all of that.

The naming diverged for political/product reasons, not technical ones. "Dynamic CI Group" is the user-facing, certification-friendly, ITIL-adjacent language that the product team chose because it fits into the narrative of CMDB Groups, CI grouping, and the Data Foundations/CSDM story. "Query Based Service" is the honest technical description of what it actually does. You ended up with:

Layer	Name
Table name	cmdb_ci_query_based_service
Parent table	cmdb_ci_service (Service Instance)
UI / Cert label	Dynamic CI Group

So yes — it absolutely quacks like a duck. It extends Service Instance, it has service health, it participates in dependency views, it behaves like a service in every functional way. The label "Dynamic CI Group" was chosen to make it feel approachable to CMDB administrators who think in terms of grouping and filtering CIs, rather than confusing them with service modeling concepts before they're ready for that conversation.

[aasch]

Hi,

cheers for the explanations. I'm going to mark it as the accepted solution.

What still bugs me is that afaik there isn't actually a service that you can handpick CIs for.
So there is no counterpart to a Dynamic CI Group which would warrant the label on its own.

But the whole political/product labelling thing can make it quite hard to grasp CSDM, because I never know if an object is labelled correctly for the current viewpoint I'm taking.
The point of view and target audience for the different labels sometimes seems to "flip flop", differing between concept, module, table or even table field.

[Pavan Srivastav]

Hi,

CSDM wasn't designed top-down with a unified vocabulary. It was assembled by retroactively mapping a framework onto tables that already existed, many of which were built independently by different product teams over years. The framework language was then laid on top as a coherent narrative, but the seams show — especially when you're moving between the conceptual model, the actual tables, and the UI all at once.

The practical survival tip for the certification is arguably to always anchor yourself to the table name first, then treat every other label as a contextual alias. Once you know cmdb_ci_query_based_service is the thing, the various names it gets called become less disorienting. The table name is the one stable identifier that doesn't shift with audience or viewpoint.