CI Class Manager & Dynamic Groups

Section 1

Why the CI Class Hierarchy Matters

The CMDB is built on a class hierarchy — a tree of CI types that inherit attributes from parent classes. You already know this from Part 1 (CMDB Architecture). At the top is cmdb_ci (all CIs), below it are categories like cmdb_ci_hardware, cmdb_ci_software, and so on.

Managing this hierarchy correctly matters because:

IRE Identification Rules are class-specific: If you put CIs in the wrong class, wrong rules apply
Reconciliation Rules are class-specific: Field authority is configured per class
Discovery patterns target specific classes: A pattern for Linux servers only runs against CIs in the Linux server class
Reports and dashboards filter by class: A "server count" report counts only CIs in server classes
CSDM mapping requires correct classes: The Common Service Data Model maps business services to specific CI classes

🌳

Analogy — CI Classes as Biological Taxonomy The CMDB class hierarchy is like biological taxonomy. Kingdom → Phylum → Class → Order → Family → Genus → Species. A server is Kingdom=IT_Asset → Phylum=Hardware → Class=Computer → Order=Server → Family=Linux_Server → Genus=RHEL_Server. Each level inherits characteristics from the level above and adds its own specific attributes. Putting a Windows server in the Linux server genus causes problems — it inherits the wrong attributes and gets the wrong rules applied.

Section 2

CI Class Manager — Viewing and Extending the Hierarchy

The CI Class Manager is a ServiceNow application that provides a visual tree-browser for the entire CMDB class hierarchy. It replaces the older approach of manually editing database tables (dictionary records) to add CI classes.

Accessing CI Class Manager

Navigate to Configuration → CI Class Manager. The main view shows:

A collapsible tree of all CI classes, from cmdb_ci root to leaf classes
The number of CIs in each class
Which classes have Identification Rules configured (green checkmark)
Which classes are "custom" (added by your organization) vs. "baseline" (shipped by ServiceNow)

Using CI Class Manager to Extend the Hierarchy

When you need a new CI class for a device type not in the baseline (e.g., a custom IoT sensor, or a specialized appliance), CI Class Manager is the correct tool. It guides you through:

Select the parent class: Which existing class best represents the new device type? Your new class will inherit its attributes.
Name the new class: Must follow ServiceNow naming conventions (cmdb_ci_ prefix)
Add custom attributes: Fields specific to this device type that don't exist on the parent class
Create Identification Rules: CI Class Manager prompts you to create rules after class creation
Create Reconciliation Rules: Optionally configure source authority for the new class's fields

⚠

Exam Pattern — CI Class Manager Is the Correct Way to Extend Classes Do not directly modify the database schema (cmdb_ci_* tables) or add dictionary entries manually to create new CI classes. CI Class Manager handles the internal table extension, parent-child inheritance, and IRE rule scaffolding correctly. Direct table modifications can break IRE, Service Mapping, and CMDB Health checks. The exam may ask: "What tool should an admin use to add a new CI type to the CMDB?" Answer: CI Class Manager.

Section 3

Extending Baseline Classes — The Upgrade-Safe Approach

ServiceNow baseline classes (like cmdb_ci_linux_server) are owned by ServiceNow. When you upgrade ServiceNow, these classes may be updated — new fields added, existing fields renamed.

Two approaches for adding fields to capture organization-specific data:

Approach	Method	Upgrade Safety	When to Use
Extend the Baseline Class	Create a new child class under the baseline parent. Add custom fields to the child class.	Safe — parent class upgrades don't affect your child class	When the device type is genuinely a subcategory of the parent (e.g., a specific server model)
Add Fields to a Baseline Class	Add custom dictionary fields directly to the baseline CI class table	Risky — ServiceNow upgrades can overwrite or conflict with custom fields	Only when absolutely necessary; custom fields must follow naming conventions (u_ prefix) to avoid conflicts

The preferred approach for the CIS-DF exam is: extend the class hierarchy, don't pollute baseline classes with custom fields. CI Class Manager supports both approaches but guides you toward class extension.

💡

Tip — Customer Fields Must Use u_ Prefix When you must add a custom field to a baseline CI class (instead of extending it), the field name must start with u_ (the "user" prefix). This tells ServiceNow that this is a customer-added field and prevents naming conflicts with ServiceNow-owned fields during upgrades. CI Class Manager enforces this automatically.

Section 4

Dynamic CI Groups — Smart, Condition-Based CI Collections

A Dynamic CI Group (also called CI Group) is a saved query that dynamically evaluates which CIs belong to the group at any given time. Unlike a static list of CIs, a Dynamic CI Group membership is always current — as CIs are added, modified, or removed from the CMDB, the group automatically includes or excludes them based on the defined condition.

Why Dynamic Groups Matter

Without Dynamic CI Groups, targeting Discovery, monitoring, or change management processes at a specific subset of CIs requires manually maintaining a list. If servers are added or decommissioned, someone must update the list. Dynamic groups solve this maintenance burden:

Discovery scoping: "Run this Discovery Schedule against all Linux servers in the Production environment" — the group auto-updates as servers are added or decommissioned
Change management: "This change affects all CIs in the Finance cost center" — group membership reflects current Finance-owned CIs
Monitoring: "Alert me when any CI in the Critical Production group goes down"
CMDB Health reporting: "Show data quality metrics for all cloud CIs"

🏷

Analogy — Dynamic Groups as Smart Playlists A Dynamic CI Group is like a smart playlist in a music app. You don't manually add songs — you define a rule: "Genre = Jazz AND Year > 2010." The playlist automatically includes any new jazz song added to your library that meets the criteria. When a song's genre tag changes, it drops off the list. The list is always current without manual work.

Section 5

Creating Dynamic CI Groups — Configuration Details

Navigate to Configuration → CI Groups → Dynamic CI Groups (or All → CI Group).

Key Configuration Fields

Field	Purpose	Example
Name	Human-readable name for the group	"Production Linux Servers"
CI class	Which CMDB table the condition runs against	cmdb_ci_linux_server
Condition	The filter query that defines membership. Uses standard ServiceNow query builder.	environment=Production AND operational_status=1 (Operational)
Include child classes	Whether CIs from subclasses of the CI class are included	If checked and class=cmdb_ci_server, includes Windows, Linux, Unix servers
Active	Whether the group is currently evaluated	Inactive groups are not included in Discovery scoping or other uses

Viewing Group Membership

After creating a Dynamic CI Group, click "View Members" to see all CIs currently matching the condition. This preview helps verify your condition before using the group in Discovery or monitoring.

💡

Key Concept — Groups Evaluate in Real Time Dynamic CI Group membership is not cached — it evaluates the condition query every time the group is referenced. If you add a new server with environment=Production, it immediately appears in the "Production Linux Servers" group the next time the group is evaluated (e.g., when Discovery runs using it as a scope). No manual refresh needed.

Section 6

Dynamic CI Groups and Discovery Integration

One of the most powerful uses of Dynamic CI Groups is scoping Discovery schedules. Instead of specifying IP ranges for Discovery (which are static and require updates when IPs change), you can target a Dynamic CI Group — Discovery will run against all CIs in the group.

CI-Based Discovery vs. IP-Based Discovery

Approach	How It Works	Advantages	Limitations
IP-Based Discovery	Discovery Schedule targets IP ranges (e.g., 10.0.0.0/24). Scans all IPs in range.	Finds new/unknown devices. Works without existing CMDB data.	Scans unknown IPs; must update ranges when network changes. Might discover unwanted devices.
CI Group-Based Discovery	Discovery Schedule targets a Dynamic CI Group. Uses CIs' stored IPs to connect directly.	Only rescans known, managed CIs. No wasted scans on empty IPs. Automatically adapts to CI changes.	Cannot discover brand-new CIs not yet in CMDB. Requires existing CMDB data.

Best practice: use IP-based Discovery for initial population and discovery of new devices. Use CI Group-based Discovery for routine refresh of known CI data (faster, more targeted).

⚠

Exam Pattern — CI Group Discovery Requires Existing CMDB CIs A Dynamic CI Group-based Discovery Schedule can only re-discover CIs that already exist in the CMDB — it uses stored IP addresses. It cannot discover brand-new devices. To populate the CMDB from scratch, you must use IP-range Discovery first. The exam may ask "why does CI Group Discovery not find newly provisioned servers?" — because those servers haven't been discovered yet and aren't in the group.

Section 7

Static vs. Dynamic CI Groups — Choosing the Right Type

ServiceNow supports both static CI groups (manually maintained lists) and dynamic CI groups (condition-based). Each has valid use cases:

Feature	Static CI Group	Dynamic CI Group
Membership definition	Manual: administrator adds/removes specific CIs	Automatic: condition query evaluated at runtime
Stays current automatically	No — requires manual updates as CIs change	Yes — membership always reflects current CMDB state
Best for	One-time exceptions, project-specific lists, or highly curated groups	Ongoing operational groupings (production CIs, by environment, by cost center)
Risk	Stale membership if not maintained	Wrong CIs included if condition is poorly written

For the CIS-DF exam, Dynamic CI Groups are emphasized because they represent the "right" approach for ongoing CMDB management — they automatically stay current with the CMDB, reducing administrative burden and risk of human error.

Exam Quick Reference

CI Class Manager & Dynamic Groups — Key Facts

CI Class Manager = tool for viewing, extending, and managing the CMDB class hierarchy. Correct tool for adding new CI types.
Never modify baseline class tables directly. Use CI Class Manager to extend hierarchy safely.
Extend classes (create child class) to add device-specific attributes — upgrade-safe.
Custom fields on baseline classes must use u_ prefix to avoid upgrade conflicts.
Dynamic CI Group = condition-based CI collection. Membership auto-updates as CMDB changes. No manual maintenance.
CI Group-based Discovery targets known CIs by their stored IP. Cannot discover new CIs not yet in CMDB.
IP-range Discovery for initial population. CI Group Discovery for ongoing refresh of known CIs.
Static CI Groups = manually maintained. Good for exceptions or one-time uses, not ongoing operations.
"Include child classes" checkbox on Dynamic CI Group — when checked, the group includes CIs from all subclasses of the selected CI class.

Term Grid

CI Class Manager

ServiceNow application for viewing the full CMDB class hierarchy, creating custom CI classes, and managing Identification/Reconciliation Rules per class. Correct tool for extending CMDB schema.

Dynamic CI Group

A CI collection defined by a condition query. Membership is evaluated at runtime — automatically includes/excludes CIs as the CMDB changes. Used for Discovery scoping, monitoring targeting, and change management.

Extend Class

CI Class Manager operation that creates a new child CI class under a selected parent. Child inherits parent attributes and can add new custom fields. The upgrade-safe way to add CI types.

Static CI Group

A manually maintained list of specific CIs. Does not auto-update. Requires administrator intervention when CIs are added or removed. Better for exceptions than ongoing operations.

u_ Prefix

Required prefix for custom fields added to baseline ServiceNow CI class tables. Prevents naming conflicts with ServiceNow-owned fields during platform upgrades.

CI Group-Based Discovery

Discovery Schedule configured to target a Dynamic CI Group instead of IP ranges. Uses stored CI IP addresses for direct connection. Cannot discover CIs not already in the CMDB.

Exam Checkpoint

Practice Questions

Click any question to reveal the answer and explanation.

1. An administrator needs to add a new CI class for a proprietary network appliance that doesn't fit any existing class. What is the correct tool and approach?

A) Directly add a new table to the ServiceNow database schema

B) Use CI Class Manager to extend the most appropriate parent class (e.g., cmdb_ci_netgear_device), adding custom fields for the appliance

C) Rename an existing unused CI class to match the new device type

D) Use Import Sets to create records in the closest matching existing class

💡 Which tool handles CI class extensions safely without breaking upgrades?

Answer: B — CI Class Manager is the correct tool for extending the CMDB class hierarchy. It guides the administrator to select a parent class, name the new class (with cmdb_ci_ prefix), add custom fields, and then creates the Identification Rule scaffold. Direct table additions (A) bypass CI Class Manager's upgrade-safety mechanisms. Renaming classes (C) would break any existing CIs in that class and its associated IRE rules.

2. A team creates a Dynamic CI Group with condition: CI class=cmdb_ci_linux_server AND environment=Production AND operational_status=Operational. A new Linux server is provisioned in the Production environment and is discovered by Discovery. When will it appear in this group?

A) Never — group membership is static after creation

B) Only after an administrator manually refreshes the group

C) Automatically — when the group is next evaluated (e.g., when a Discovery Schedule using this group runs), because the new CI matches the condition

D) After 24 hours, when a scheduled synchronization runs

💡 Dynamic CI Groups evaluate their condition at runtime. What does "runtime" mean here?

Answer: C — Dynamic CI Group membership is evaluated at runtime each time the group is referenced. Once the new server is created in the CMDB (after Discovery and IRE process it with environment=Production and operational_status=Operational), it automatically satisfies the group condition. The next time a Discovery Schedule using this group runs, the new server is included in scope. No manual refresh or wait period is needed.

3. A Discovery Schedule is configured to use a Dynamic CI Group "All Production Servers" instead of IP ranges. A new server is provisioned with IP 10.0.5.100. It is NOT yet in the CMDB. Will this Discovery Schedule discover the new server?

A) Yes — the Dynamic CI Group updates automatically to include new IP addresses in the Production network

B) No — CI Group-based Discovery only targets CIs already in the CMDB. The new server is not in the CMDB yet, so it's not in the group.

C) Yes — Discovery automatically expands its scope to adjacent IP addresses

D) Yes — as long as the IP is reachable from the MID Server

💡 What does CI Group-based Discovery use to connect to CIs?

Answer: B — CI Group-based Discovery uses the IP addresses stored in existing CMDB CI records. If a server is not yet in the CMDB, it has no CI record, so it cannot be in the group, and Discovery cannot target it. To discover new servers, you need either IP-range Discovery (which scans all IPs in a range) or use a separate Discovery Schedule with IP ranges to initially find new devices before CI Group-based Discovery can maintain them.

4. An administrator wants to add a custom field called "data_classification" to the baseline cmdb_ci_server class to track if servers store sensitive data. What naming convention must the field name follow?

A) data_classification (no prefix needed)

B) sys_data_classification (sys_ prefix for system fields)

C) u_data_classification (u_ prefix for customer-added fields)

D) cmdb_data_classification (cmdb_ prefix to indicate it's a CMDB field)

💡 What prefix prevents naming conflicts with ServiceNow-owned fields during upgrades?

Answer: C — Custom fields added to baseline ServiceNow tables must use the u_ prefix (standing for "user" or "customer"). This prefix prevents naming conflicts if ServiceNow later ships a baseline field with the same name. sys_ is for ServiceNow system fields. The correct field name would be u_data_classification. CI Class Manager enforces this convention when you add fields through its interface.

5. An operations team wants to ensure their weekly Deep Discovery scan targets only servers in the "Production" and "Staging" environments. They don't want to maintain a static IP list. What is the best approach?

A) Create separate IP ranges for Production and Staging networks, update them manually when servers move

B) Create a Dynamic CI Group with condition: environment IN (Production, Staging), then configure the Discovery Schedule to target this group

C) Run Discovery against the entire data center and filter results in reports afterwards

D) Create a static CI Group with all current Production and Staging servers, update it weekly

💡 Dynamic CI Groups auto-update when CIs' attributes change. How does this solve the maintenance problem?

Answer: B — A Dynamic CI Group with condition environment IN (Production, Staging) is the ideal solution. When servers are added to Production or Staging environments in the CMDB, they automatically join the group. When decommissioned (environment changed or operational_status changed to Retired), they automatically leave the group. No manual list maintenance required. This is exactly the use case Dynamic CI Groups are designed for: ongoing operational targeting without administrative overhead.

Exam Checkpoint

Practice Questions

4 questions · Select an answer to see the explanation immediately.

CI Class Manager & Dynamic Groups Quiz 1 / 4

An administrator needs to add a new CI class for a proprietary appliance. What is the correct tool and method?

💡 Explanation

B is correct. CI Class Manager is the correct tool for extending the CMDB class hierarchy. It guides the administrator to select a parent class, name the new class (with cmdb_ci_ prefix), add custom fields, and creates the necessary scaffolding including IRE rule stubs. Extending (not modifying) is upgrade-safe. Direct table additions (A) bypass upgrade safety. Renaming (C) breaks existing CIs in that class and all associated IRE rules. Custom fields must use the u_ prefix if added to baseline classes.

CI Class Manager & Dynamic CI Groups — Managing the CMDB Schema and Smart Groupings

Why the CI Class Hierarchy Matters

CI Class Manager — Viewing and Extending the Hierarchy

Accessing CI Class Manager

Using CI Class Manager to Extend the Hierarchy

Extending Baseline Classes — The Upgrade-Safe Approach

Dynamic CI Groups — Smart, Condition-Based CI Collections

Why Dynamic Groups Matter

Creating Dynamic CI Groups — Configuration Details

Key Configuration Fields

Viewing Group Membership

Dynamic CI Groups and Discovery Integration

CI-Based Discovery vs. IP-Based Discovery

Static vs. Dynamic CI Groups — Choosing the Right Type

CI Class Manager & Dynamic Groups — Key Facts

Term Grid

Practice Questions

Practice Questions