How to Use the Blueprint Library

ServiceNow data quality templates: define what good data looks like once

Improving ServiceNow data quality becomes much easier when teams do not have to start from scratch every time.

Many organizations know they need better CMDB, CSDM, and foundation data. The harder question is turning that goal into clear and repeatable requirements.

What should a Business Application record contain? Which relationships are expected for a service? What makes a support group valid? Which foundation data fields are actually required for reporting, routing, ownership, or governance?

ServiceNow data quality templates give teams a reusable starting point for answering those questions.

Instead of defining data quality separately for every project, table, or team, a template describes what good data should look like for a specific object or use case. That definition can then be reused for auditing, remediation, certification, and reporting.

About this guide: This article is based on the above DCM Open House walkthrough in which the DCM team demonstrates how DCM Blueprints can be used as reusable ServiceNow data quality templates and applied across CMDB and foundation data.

Why reusable data quality requirements matter in ServiceNow

ServiceNow data rarely supports only one process.

The same Business Application, user, group, location, service, or configuration item may be used across IT service management, operations, asset management, application portfolio management, reporting, governance, automation, and AI.

That creates a problem when different teams define quality differently.

One team may consider a Business Application complete when it has an owner and lifecycle status.

Another may also expect:

• A technical owner
• A support group
• Business criticality
• A relationship to the relevant service
• Other data needed for reporting or governance

Neither definition is automatically wrong.

The problem is that if every team creates its own requirements independently, it becomes much harder to compare results, assign responsibility, scale audits, or explain what “good data” actually means.

Reusable templates create a shared baseline without forcing every use case to be identical.

What is a ServiceNow data quality template?

A ServiceNow data quality template is a reusable model that defines the expected requirements for a particular type of data.

It can describe:

• Which attributes should be populated
• Which relationships should exist
• Which ownership information is required
• Which values should be considered valid
• Which conditions indicate a data quality problem
• Who should review or maintain the data
• What should happen when the data does not meet the expected standard

The important part is that the template is not simply a list of mandatory fields.

A useful template connects the requirement to a purpose.

For example, ownership information may matter because remediation needs to be routed to someone. A service relationship may matter because teams need reliable impact analysis. A lifecycle value may matter because reporting and automation need to distinguish current records from retired ones.

This is also the idea behind the DCM Blueprint Library: reusable data models give teams a starting point that can then be adapted to their own ServiceNow environment.

Use templates to standardize both attributes and relationships

A common data quality mistake is to focus only on fields.

In ServiceNow, relationships can be just as important.

A Business Application may have every required field populated but still be difficult to use if it is not connected to the right services. A server may exist in the CMDB but still lack the service context required for impact analysis. A location may be populated but point to a record that is no longer operational.

A useful template can therefore define both:

• Attribute requirements – such as ownership, lifecycle, support groups, criticality, or identifiers
• Relationship requirements – such as connections between applications, services, infrastructure, owners, or foundation records

This makes the resulting audit much closer to the way the data is actually used.

If you want to see how these models are created in practice, the how to design a DCM Blueprint walkthrough goes deeper into the modelling process.

Different data domains need different templates

There is no single set of data quality rules that makes sense for every ServiceNow table.

That is one reason reusable, focused templates are more practical than trying to build one enormous “CMDB quality” checklist.

For example:

Business Applications

A template may focus on ownership, lifecycle, business criticality, support information, and relationships to the services that represent the application operationally.

Services and configuration items

The important requirements may include ownership, support groups, lifecycle information, and relationships that provide operational and service context.

Foundation data

Templates may be used for users, groups, companies, departments, locations, or cost centers, with requirements based on the processes that depend on that data.

The more clearly the template is tied to one type of data and one useful outcome, the easier it becomes for data providers to understand what is expected.

Turn expert knowledge into something the wider organisation can reuse

Without templates, data quality often depends heavily on individual knowledge.

One architect may know which Business Application fields matter. A CMDB manager may understand which relationships regularly go missing. Someone in the platform team may know which support-group rules are essential for routing.

That expertise is valuable, but it is difficult to scale if it stays informal.

Templates make those expectations explicit and reusable.

Instead of explaining the same requirements manually every time a new project starts, teams can establish a model and apply it repeatedly.

That also makes onboarding easier. New teams do not need to rediscover what good data means from scratch.

From template to audit: check the data against the model

Defining the template is only the first step.

The next question is whether the live ServiceNow data actually meets those requirements.

A repeatable process can look like this:

1. Choose the data area or use case you want to improve.
2. Select or create a template defining what good data looks like.
3. Audit the existing ServiceNow records against that template.
4. Review the findings with the relevant data owners or providers.
5. Assign remediation work for gaps that need to be corrected.
6. Use certification where human validation is needed.
7. Track progress and refine the requirements over time.

The ServiceNow data quality audit walkthrough shows the auditing side of that process in more detail.

The important shift is from an occasional clean-up exercise to a repeatable operating model.

Use certification when a rule cannot tell you whether the data is actually correct

Templates and audits are useful for checking whether defined conditions are met.

But automation cannot answer every quality question.

A rule can tell you that a Business Application has an owner.

It cannot always tell you whether that person is still the correct owner.

A rule can verify that a relationship exists.

It may not know whether that relationship reflects the real operational environment.

That is where ServiceNow data certification becomes useful.

Certification adds human validation to the template-based process. Instead of simply asking whether a field is populated, teams can ask the people closest to the data whether the information is actually accurate and fit for purpose.

The June Open House on blueprint-based data certification shows how the same data quality model can be reused to structure that review.

Templates should be starting points, not rigid universal rules

Reusable does not mean inflexible.

A template should provide a strong baseline, but organisations may need to adapt it based on:

• Their ServiceNow configuration
• Their CSDM maturity
• The processes that consume the data
• Their ownership model
• Regulatory or governance requirements
• The systems that create or maintain the data

This is especially important when a standard template is imported into an environment with established local practices.

The right question is not:

“How do we force every record to match this template?”

It is:

“Which of these requirements are necessary for the outcome we want, and what do we need to adapt?”

Avoid templates that are too broad

Another risk is making the template so generic that nobody knows what to do with it.

A single “CMDB data quality template” may sound convenient, but it can quickly become a long list of unrelated checks.

Focused templates are usually easier to understand and act on.

For example:

• Business Application data quality
• Server relationships
• Service Instance data
• Support groups
• Locations
• Users and groups

Each can define requirements that match the specific role that data plays in ServiceNow.

This also makes ownership clearer because the people responsible for one domain do not need to work through findings that belong to another.

Do not stop at completeness

A populated field is not necessarily a correct field.

A successful template-based approach therefore needs to look beyond simple completeness.

Depending on the use case, quality rules may also need to consider:

• Validity
• Relationships
• Ownership
• Lifecycle
• Consistency
• Duplicates
• Whether referenced records are still active
• Whether the data remains relevant to the process using it

This is what turns a template from a field checklist into a meaningful definition of trustworthy data.

Start with one high-value use case

You do not need to standardize every ServiceNow data domain at once.

A better starting point is one area where poor data quality is already creating visible friction.

That might be:

• Missing application owners
• Unreliable service relationships
• Invalid support groups
• Inconsistent lifecycle values
• Incomplete location or foundation data
• Data that regularly causes reporting or routing problems

Define the minimum requirements for that use case first.

Then decide how the template will be used. Will it support an audit? Remediation? Certification? Governance reporting? CSDM improvement? AI-readiness?

That purpose should determine how detailed the first version needs to be.

Once the template works for a real use case, you have something concrete to refine and reuse elsewhere.

Make templates part of the data quality operating model

The real value of reusable templates is not the template itself.

It is what happens around it.

A good template gives teams a shared definition of what good data looks like. Audits measure the live environment against that definition. Ownership determines who can correct the gaps. Certification provides human validation where rules are not enough. Reporting shows whether the process is improving.

Together, these steps make data quality repeatable.

That is also why templates connect naturally to ServiceNow data governance. Standardization becomes much more useful when expectations, ownership, remediation, and accountability are all connected.

For teams using DCM, Blueprints provide the reusable model for this process. But the broader principle applies regardless of tooling: ServiceNow data quality becomes easier to scale when people share a clear definition of what good data looks like.