OBLYTECH Logo
Enquire Now
OBLYTECH Logo

ServiceNow / Practical guide

ServiceNow Configuration Items: A Clear Definition for Teams

A ServiceNow configuration item is useful when it helps a team understand a service, dependency, ownership decision, change effect, or operational risk. The record is not valuable simply because it exists in a CMDB.

For service owners and configuration teams clarifying what should be represented as a configuration item..

ServiceNow configuration itemsCI definitionCMDB records
Discuss this ServiceNow topic

Guide map

Turn configuration item definitions into a repeatable review.

Define a configuration item by its operational use

A record earns its place when it changes how someone reviews or explains a service.

Distinguish assets, services, and configuration items

Keep the three terms separate in reports, because each one answers a different question.

Give the item an owner and lifecycle

Name who maintains the data and who answers for what the item means.

The practical framework

Learn how to define ServiceNow configuration items by the decisions they support, their ownership, relationships, lifecycle, and review needs.

That distinction helps teams avoid two opposite mistakes: recording everything without a use case, or recording so little that an incident or change review has no useful context.

Define a configuration item by its operational use

Ask what decision the item will support. Will an analyst use it to identify a responsible group? Will a change owner review its dependency on a service? Will an operations team connect it to an alert? Will a service owner use it to understand lifecycle or risk?

The answer should influence the attributes and relationships required. An item that cannot support a named decision may be a candidate for a later scope or a different record type.

Distinguish assets, services, and configuration items

An asset often represents ownership, value, lifecycle, or financial responsibility. A business service represents something people rely on. A configuration item represents a component or logical element whose state, relationship, or ownership matters to service management.

The records can relate to one another, but they should not be treated as interchangeable. A device may be an asset and a configuration item. A business service may depend on many configuration items without being a physical asset. Clear definitions prevent reports from answering the wrong question.

The ServiceNow health checks and audits service is the relevant internal route when CI definitions, data quality, and ownership need a structured review.

Give the item an owner and lifecycle

Ownership should explain who can challenge the record, correct its attributes, approve a relationship, and decide what happens when the item changes or retires. A technical contact may maintain data while a service owner remains accountable for the operational meaning.

Lifecycle states should have a reason. “Active,” “retired,” or “pending” should lead to an understood action rather than being labels that no process uses. If a state cannot be reviewed or changed responsibly, it will become stale.

Relationships make the record useful

Relationships show how components support services, depend on one another, or share an owner. They should be specific enough to help an analyst or reviewer, but not so detailed that the team cannot maintain them.

Review relationship quality separately from record completeness. A well-populated item with no useful connection may still fail to explain impact. A relationship that is assumed rather than verified can create false confidence during an incident or change.

Avoid classes that nobody can review

Each new CI class creates naming, ownership, lifecycle, relationship, and quality work. Add a class when it supports a decision the team can explain and review. Do not add one merely because a source system exposes the object.

The ServiceNow consulting service can help align configuration definitions with the service and operating model before a wider implementation.

Common questions

Questions teams ask about configuration items

Is every device a configuration item?

No. A device belongs in the CI scope when its state, ownership, relationship, or impact matters to the service-management decision being supported. Asset and inventory records may satisfy other purposes.

What makes a CI trustworthy?

A clear definition, accountable owner, useful lifecycle, reviewed attributes, and meaningful relationships. Trust comes from how the record is used and maintained, not from its presence in a table.

The research-grounded boundary

Configuration items are only as useful as the decisions they help someone make. Before a class or record is added, the team should be able to name the owner, the review trigger and the question it answers. Records that cannot be checked against a real service or change tend to drift out of date, and a stale record can mislead a review more than a missing one would.

Start from the class decision, not the record count

In a CMDB the hard choice is rarely whether a server belongs in the database. It is which class a thing should sit in, and whether a class is worth maintaining at all. A class decides which attributes exist, which relationships are expected and which team gets the first call when the record is wrong. Choosing a class is therefore a small operating decision with lasting consequences, and it should be made by someone who will answer for the record afterwards.

The working question is what a reviewer will do with the item. A network engineer comparing a fault with its upstream device needs a different class and relationship set from a finance analyst reconciling licenses to hardware. If a proposed class does not serve one of those reviews, it is probably a copy of a source system’s object model rather than a configuration decision.

Map each candidate class to the decision it supports

The table below is a method for reviewing a proposed class before it goes into the model. Each row turns a class into a set of obligations, and the obligations are what make the class expensive or cheap to run.

Question for the proposed classWhat a good answer looks likeWarning sign
Which incident or change decision uses it?A named review step, such as impact assessment before a changeThe only use is a dashboard nobody opens
Who corrects its attributes?One team, with a stated route for requestsSeveral teams can edit the same field with no owner
Which relationships are expected?A short list of relationship types that a reviewer would checkEvery relationship type is available and none is required
Where does its data come from?A discovery source, an import with a named owner, or a manual process with a review dateNo source at all, only hand entry by whoever noticed the gap
What retires it?A defined lifecycle state and the action that follows itRetired items still appear in impact views

If a class fails several of these questions, park it. A parked class can be reconsidered when a real decision needs it, and the cost of waiting is usually lower than the cost of maintaining an empty class.

Sequence for adding a class to the model

Once a class passes the table, the work of adding it should follow a fixed order, so that no record is created before its purpose is written down.

  1. Write the decision the class supports and the reviewer who will use it, in one paragraph attached to the design record.
  2. Agree the attribute set, marking each attribute as required, optional or derived from another source.
  3. Define the relationships the class needs and the direction in which they should be read.
  4. Name the owner for the class and the owner for each important attribute, where those differ.
  5. Load a small, reviewed sample and check it against a real incident or change, not against a list of hosts.
  6. Open the class to general use only after the sample has answered the decision question without help from the design author.

The sample in the fifth step is a test many teams skip. A class that looks tidy in a design document often fails the first time someone tries to explain a real outage with it, and that failure is cheaper to discover in a sample than in production.

The mistakes that create unreliable CI records

A CI record becomes untrustworthy in predictable ways. Records are created by hand during an urgent piece of work and never revisited. Attributes are filled from memory with values that look plausible. Relationships are drawn from a diagram made for a project that has since changed. Each mistake is small, but together they give analysts a model that looks complete and behaves unpredictably during an incident.

A useful defense is a review cadence tied to use. When a record is used in an incident or change review, the reviewer checks the relationships shown and records any correction. Records that never get used are the ones to question, because they are the ones nobody will notice are wrong.

When the configuration item model is the wrong tool

Not every inventory needs to be a CI model. Some assets only need to be tracked for cost and lifecycle, and a separate asset record serves that purpose more cleanly. Some software features are better described as services than as configuration items, particularly where the people who use them think in terms of outcomes. The business service starting point guide describes starting CSDM with a small, owned set of business services connected to the technical information needed for support and change decisions.

Is it better to populate CIs from discovery or from a managed list?

For infrastructure that discovery can see reliably, discovery is usually the stronger source, because the record follows the live state. For items discovery cannot see, such as a cloud service contract or a physical location, a managed list with a named owner and review date is safer. The two sources should be reconciled rather than left to compete for the same record.

What is the difference between a CI class and a CI record?

The class defines the kind of thing and the attributes it can carry. The record is one instance of that kind, such as one specific application server. Problems usually come from changing the class design while records already depend on it, so class changes should be reviewed like schema changes.

Which people may create CI records by hand?

Only people who can explain the source of the values they enter, and who will be contacted if the record is questioned. Ad hoc creation during an incident is sometimes necessary, but the record should carry a note and a review date so it does not stay as an unverified entry.

Can a relationship exist without the two items being in the same class?

Yes, and that is often the point. A service can depend on several classes of configuration item, and the relationship records show how they connect. The design question is whether the reviewer needs that connection to make a decision, not whether the classes match.

Review the CI model before it spreads

A short review of proposed classes, relationships and owners is usually cheaper than cleaning a model after it has been loaded with thousands of records. If a class list has grown without a stated decision behind each entry, the review can start with the table above. The configuration item definitions page describes defining classes, attributes, ownership, lifecycle and relationships around operational decisions.

A practical next step

Need a clearer ServiceNow operating model?

OBLYTECH can discuss the questions raised by this guide and the next review step. See the ServiceNow consulting services page for the commercial route.

Useful starting pointBring the current question, scope, ownership concerns, and evidence needs into the first review conversation.

Review ServiceNow consulting

ServiceNow guides on this topic

Guides from the Oblytech ServiceNow library that explain the practice behind this page.

More from the blog

Related reading