Make service instances visible, connected, and accountable

Service Instances in ServiceNow: connect the operational service model

Service Instances sit at an important connection point in the CSDM model. They can provide the operational context between applications, underlying infrastructure, services, and the people responsible for maintaining them.

A Service Instance may exist in ServiceNow but still be difficult to use if it is not connected to the right Business Application, supporting infrastructure, or responsible team. The record is there, but much of the context needed for impact analysis, ownership, governance, and ongoing maintenance is missing.

In this DCM Blueprint Live recording, Mikko Juola explores how to improve Service Instances in ServiceNow using the Service Instances – CSDM 5 Crawl Blueprint. The session focuses on defining a practical minimum model, auditing live data, assigning responsibility, and giving people a structured way to maintain both records and relationships.

What a Service Instance needs at the CSDM Crawl stage

At the Crawl stage, the goal is not to model every possible service relationship.

The focus is on establishing enough context to make the Service Instance usable and accountable.

In the webinar, the Service Instances – CSDM 5 Crawl Blueprint focuses on three main areas:

• Relationships to underlying configuration items
• A relationship to the relevant Business Application
• Clear responsibility for the Service Instance

The underlying configuration items might include servers, applications, middleware, or other infrastructure depending on the type of Service Instance.

Servers are one obvious example of that supporting infrastructure. But having a server in the CMDB does not automatically mean the relationship to the service is complete or correct. The Server Relationships in ServiceNow Blueprint Live recording looks specifically at how to identify servers that are missing that service context and how those gaps can be audited and assigned.

The Business Application relationship provides another important piece of context by connecting the operational instance to the application it supports.

Responsibility should also be established from the beginning. That might be represented through an owner, manager, support group, Managed by group, or another role that fits your organisation.

Together, these relationships create a practical baseline that can be audited and improved over time.

How Service Instances fit into CSDM 5

In CSDM 5, Service Instance is a broader concept covering several types of operational service instance. Application Service remains part of that model, alongside other Service Instance classes used for areas such as data and network services.

ServiceNow's own CSDM 5 documentation shows Service Instances within the wider CSDM relationship model, including their relationships with Application Services and other parts of the operational service structure.

This matters because not every Service Instance needs exactly the same detailed requirements.

A Service Instance representing an application service may need different infrastructure relationships from a Data Service Instance or another specialized type. A useful Blueprint therefore needs enough consistency to define shared requirements while still allowing validation rules to vary by Service Instance type.

Make responsibility part of the Service Instance model

A recurring challenge with Service Instance data is scale.

It may be relatively easy for a small CMDB team to define what a good Service Instance should look like. It is much harder for that same team to know the correct details for thousands of individual records.

The people closest to the service usually know the operational context best.

That is why responsibility is part of the Blueprint demonstrated in the session.

A Service Instance should reference at least one relevant person or group so that there is someone who can review the data, correct missing details, and validate relationships.

This changes the operating model from:

“The CMDB team has to fix every Service Instance.”

to:

“The CMDB team defines the model, and the right data providers maintain the records they understand.”

That makes Service Instance governance much more scalable.

Audit missing Service Instance relationships and responsibilities

Once the Blueprint is defined, DCM can audit existing Service Instance data against those requirements.

The webinar example shows findings such as:

• Missing Business Application relationships
• Missing Managed by groups
• Missing managers
• Missing or invalid ownership information
• Missing required infrastructure relationships
• Other field-level requirements that do not match the Blueprint

The audit gives the team responsible for the Service Instance domain an overview of where the biggest gaps are.

It can also be filtered by individual data providers or groups.

That makes it possible to move from a broad data-quality problem to a much more practical question:

Which Service Instances belong to this team, and what exactly needs to be fixed?

Instead of expecting one central team to clean everything, findings can be distributed to the people already responsible for the relevant applications, services, or infrastructure.

Turn Service Instance audit findings into manageable work

An audit is useful only if people can act on the findings.

The webinar demonstrates how a data provider can use the DCM My Data Quality Workspace to see the Service Instances they are responsible for and the issues affecting each one.

For example, a Service Instance might be missing a Managed by group, have an inactive owner, or lack a relationship to the correct Business Application.

Instead of navigating through several different ServiceNow tables and trying to determine what the problem is, the data provider can see the detected issue and work directly from the finding.

This helps reduce the gap between identifying poor Service Instance data and actually improving it.

Use the Content Planner to maintain Service Instance relationships

Relationships are often the most important part of Service Instance data, but they can also be some of the hardest information to maintain.

The DCM Content Planner provides a visual way to work with those relationships.

In the webinar, the Blueprint is shown in the background while existing records are placed on top of it. A user can then find the correct Business Application, server, or other related record and connect it to the Service Instance.

This is particularly useful when several relationships need to be reviewed or created at the same time.

For example, a Service Instance may need to be connected to:

• The relevant Business Application
• One or more servers
• Other application or infrastructure records
• An owner
• A support group

The Content Planner gives the user a clearer view of how those records fit together before the changes are committed.

Plan new Service Instance data before writing it to the CMDB

The Content Planner can also be used to prepare completely new Service Instance data.

In the webinar example, a new Data Service Instance is created for a customer analytics production environment.

The user then adds the Business Application, server relationships, ownership, support details, and other required information.

Some of those records may already exist. Others can be planned as new records.

This means a team can build the intended data structure first, review whether the mandatory requirements have been satisfied, and then commit the changes when the model is ready.

This can be especially useful when creating a connected set of records rather than adding individual CIs and relationships one by one.

Different Service Instance types can have different requirements

A generic Service Instance Blueprint does not mean every Service Instance must be identical.

The webinar discusses how the requirements can be adjusted according to the actual Service Instance class or type.

An Application Service might have one set of expected relationships, while a Data Service Instance may require another.

The important part is to define which requirements are common and where the model needs to become more specific.

This allows one Blueprint to cover a broad Service Instance domain while still validating the differences that matter operationally.

Build the service backbone before adding more complexity

One of the practical examples in the session is the idea of creating a service backbone across the CMDB.

This means making sure that the central service-related classes are connected at a basic level before trying to introduce more detailed requirements.

That backbone can include:

• Business Services
• Service Instances
• Technology Management Services
• Service Offerings
• Business Applications
• Supporting infrastructure

Once those minimum relationships are in place, audits can progressively ask for more detailed information.

This creates a more manageable path than trying to perfect the entire CSDM model at once.

Foundation data sits underneath that service backbone as well. Records such as locations, organizations, groups, and users provide shared context used across the platform. For a practical example, the ServiceNow Location Data Blueprint Live recording shows how the same Blueprint approach can be applied to location hierarchy, responsibility, and foundation-data governance.

Start with the Service Instance relationships that matter most

If your Service Instance data is incomplete, the answer does not have to be a major modelling project.

A practical starting point is to define the minimum relationships and responsibilities you need at the Crawl stage.

That could mean:

1. Identify which Service Instance types you want to include first
2. Require a connection to the relevant Business Application
3. Define the minimum infrastructure relationships you expect
4. Make sure each Service Instance has a responsible person or group
5. Audit the current records against those requirements
6. Route findings to the teams that can validate and correct them

Once that baseline is working, the model can become more detailed.

At later CSDM stages, Service Instances can be connected more extensively to Technology Management Services, Service Offerings, Business Services, and other parts of the service model.

The important thing is to create something that can be measured, maintained, and improved rather than waiting until every possible requirement has been defined.

Use auditing and human validation together

Automated auditing can identify a missing relationship, an inactive owner, or a required field that has not been populated.

But some Service Instance questions require human knowledge.

A relationship may technically exist while still being incorrect.

For example, a Service Instance might already be connected to a Business Application or infrastructure record, but someone familiar with that service still needs to confirm that the relationship represents reality.

That is where responsibility and validation become important.

The goal is not only to make the Service Instance look complete in ServiceNow. It is to create a model that the people responsible for the service can recognise, validate, and maintain.

Related resources

If you are working on Service Instances, CSDM, or service relationships in ServiceNow, these resources can help:

• DCM Blueprint Library – explore ready-made DCM Blueprints for CSDM, CMDB, and foundation-data use cases.
• 5 Steps to Better Data Quality – a practical approach to ownership, requirements, auditing, remediation, and continuous improvement.
• Server Relationships in ServiceNow – see how servers can be connected to the Service Instances and services they support.
• ServiceNow Location Data – see how the same Blueprint approach applies to location hierarchy, ownership, and foundation data.