Data Certification Update

Blueprint-based data certification: define what good data means before asking people to review it

Data certification works best when reviewers understand exactly what they are being asked to validate.

That sounds simple, but in ServiceNow different types of data have different purposes, owners, relationships, and quality expectations.

A Business Application should not be reviewed in the same way as a server, location, Service Offering, department, or support group.

Blueprint-based data certification starts by defining what good data should look like for a specific object or use case before asking people to certify it.

Instead of sending a generic request to “review this record,” teams can define:

• Which records are in scope
• Which fields matter
• Which relationships should exist
• Which ownership details need to be valid
• Who should review the data
• What should happen when certification fails

What is blueprint-based data certification?

Blueprint-based data certification is a structured way to validate ServiceNow data against a predefined data quality model.

The blueprint defines the expected standard.

That can include:

• Mandatory attributes
• Expected relationships
• Ownership fields
• Lifecycle information
• Support groups
• Reference data
• Other criteria that make the record usable in practice

Certification then asks the right people to confirm whether the data actually meets that standard.

For example, a Business Application Blueprint might define that every record should have:

• A business owner
• A technical owner
• A lifecycle status
• A support group
• A related Application Service
• Other relationships required for reporting or impact analysis

The certification request therefore becomes much more specific than simply asking someone to approve the whole record.

For a broader overview of the concept, see ServiceNow data certification.

Why generic certification requests often fail

A generic certification request creates ambiguity.

If someone is asked to certify a record without clear criteria, they may not know what they are expected to check.

Should they confirm:

• That the record exists?
• That the owner is correct?
• That mandatory fields are populated?
• That relationships are accurate?
• That the data is still relevant?

Different reviewers may interpret the same task differently.

One person may only check completeness.

Another may validate whether the data reflects reality.

Another may approve the record because they do not have enough context to question it.

That makes the results difficult to compare and weakens confidence in what “certified” actually means.

A Blueprint helps reduce that ambiguity by giving reviewers a shared definition of what they are validating.

Use Blueprints to define what “good data” looks like

One of the biggest challenges in ServiceNow data quality is that “good data” depends on the use case.

For incident routing, good data may mean accurate support groups and assignment information.

For change impact analysis, it may mean reliable CI and service relationships.

For application portfolio management, it may mean correct ownership, lifecycle status, business criticality, and related services.

For compliance, the focus may be on ownership, classification, control-related information, and evidence.

A useful data quality Blueprint can answer questions such as:

• Which attributes are required?
• Which relationships should exist?
• Which ownership fields must be valid?
• Which values indicate that the data is incomplete or outdated?
• Who is responsible for validating it?
• Which process depends on this data?
• What happens if it fails certification?

This turns certification from a subjective review into a more consistent process.

You can explore reusable models in the DCM Blueprint Library.

Certify the data that actually supports important outcomes

Blueprint-based certification is most useful when the data supports important decisions, workflows, reporting, governance, automation, or compliance.

Good candidates include:

• Business Applications
• Application Services
• Technical Services
• Service Offerings
• Configuration Items
• Support groups
• Users
• Companies
• Departments
• Locations
• Cost centres
• Other foundation data

The strongest starting point is usually an area where poor data quality already causes visible problems.

That might include:

• Applications without valid owners
• Services without support groups
• CIs without expected relationships
• Inactive users assigned to important roles
• Foundation data causing routing or reporting issues

Certification is easier to justify when everyone understands what the data is supposed to support.

Use Blueprints to make relationship certification more meaningful

For CMDB and CSDM data, relationships can be just as important as fields.

A Business Application may look complete at record level but still be difficult to use if it is not connected correctly to its services.

Likewise, an Application Service may contain the expected fields while still having inaccurate relationships to infrastructure or other parts of the service model.

A Blueprint can define which relationships are expected.

An automated audit can then check whether those relationships exist.

Certification can go one step further and ask someone with real-world knowledge whether the relationship is actually correct.

This distinction is important:

Existence is not the same as correctness.

A rule may confirm that a relationship is present.

A knowledgeable reviewer may still need to confirm that it represents the real operational environment.

Connect blueprint-based certification to ownership

Many data quality issues are ultimately ownership issues.

The platform team may define the process, but it cannot always confirm whether every application, service, CI, or foundation record is correct.

The people closest to that data often sit elsewhere in the organisation.

They may be:

• Application owners
• Service owners
• Infrastructure teams
• Application portfolio teams
• Process owners
• Business functions
• Foundation-data owners

Blueprint-based certification makes that responsibility more concrete.

Instead of simply saying:

“The business owns the data.”

the organisation can define:

• This type of data must meet these criteria
• These fields and relationships need to be reviewed
• These people are responsible for certification
• Rejected data must lead to a follow-up action

That helps turn ownership into an operational process rather than a governance statement.

For the wider governance angle, see ServiceNow data governance.

Use audits and certification for different kinds of validation

Audits and certification complement each other.

An audit can check whether data appears to meet predefined rules.

Certification can ask whether the data is actually correct.

For example, an audit may show that every Business Application has an owner.

That does not prove that the listed owner is still responsible for the application.

Likewise, an audit can confirm that a relationship exists without proving that the relationship reflects reality.

A practical flow looks like this:

1. Define the expected data through a Blueprint.
2. Audit ServiceNow data against the Blueprint.
3. Identify records or attributes that require human validation.
4. Ask the right people to certify them.
5. Create follow-up actions for failed or rejected data.
6. Track recurring issues.
7. Improve the Blueprint, ownership model, or source process based on what you learn.

The ServiceNow data quality audits walkthrough explains the automated auditing part of that process in more detail.

Make failed certification useful

A certification process is only valuable if the result leads somewhere.

If a reviewer rejects a record and nothing happens next, the process identifies an issue without improving the data.

A failed certification may need to trigger:

• A remediation task
• A direct data correction
• An ownership update
• A review of the underlying source process
• A change to the Blueprint or audit rule
• A governance discussion

Repeated failures can also expose broader problems.

If the same type of record fails again and again, the issue may not be with individual users.

It may point to:

• An unclear ownership model
• A weak source process
• An integration problem
• A confusing data model
• A missing governance decision

This is where certification becomes a useful source of operational insight rather than only an approval process.

Avoid certifying data no one uses

Not every ServiceNow field deserves human certification.

If a field does not support a real process, decision, report, governance requirement, or automation, requiring people to review it can create unnecessary work.

A better question is:

Why does this data need to be trusted?

If there is no clear answer, teams may need to reconsider whether the field belongs in the certification scope at all.

This keeps certification focused and reduces the risk of creating reviewer fatigue.

Start with one Blueprint and one meaningful use case

The first Blueprint does not need to cover everything.

Choose one data area where quality problems are visible and the value of validation is clear.

That might be:

• Business Application ownership
• Application Service relationships
• Support groups
• Lifecycle status
• Foundation data
• Another high-value CMDB or CSDM use case

Then define:

1. The minimum data requirements.
2. The relationships that matter.
3. The people who understand the data.
4. What they need to validate.
5. What happens when something is rejected.

Run the first certification process, review what worked, and refine the Blueprint based on real findings.

Over time, the model can become more sophisticated.

The important thing is to begin with something specific enough to guide reviewers and useful enough to produce action.

Build a repeatable certification process instead of a one-time review

Blueprint-based certification is most valuable when it becomes part of continuous data quality improvement.

The combination of:

• Reusable data requirements
• Automated audits
• Human certification
• Clear ownership
• Remediation
• Trend reporting
• Governance

creates a more repeatable process than occasional clean-up campaigns.

This also means the Blueprint itself can improve over time.

Audit findings, failed certifications, reviewer feedback, and recurring issues can all show where the model needs to change.

For readers who want to see how reusable requirements are constructed, the how to design a DCM Blueprint walkthrough provides a more detailed look at Blueprint design.

The broader principle is simple: certification becomes more useful when everyone is validating data against the same clear definition of what good looks like.