How to Engage Your Data Providers

ServiceNow data providers: make data quality personal and actionable

Improving ServiceNow data quality is rarely something one CMDB or platform team can do alone.

The people who know whether an application, service, server, location, user group, or other record is correct are often spread across the organization.

They may be application owners, service managers, infrastructure teams, HR coordinators, project managers, group managers, or other subject-matter experts.

The challenge is that these people are usually not data-quality specialists.

They may not understand the CMDB, CSDM, data models, relationship types, or the technical rules behind a data-quality score.

That means simply telling people to “improve the data” is unlikely to work.

A more practical approach is to give each person a clear scope, understandable requirements, and a way to act only on the data they are actually responsible for.

Who are data providers in ServiceNow?

In the Consumer–Owner–Provider model, a data provider is the person or process responsible for creating, maintaining, or updating specific data.

The three roles have different responsibilities:

• Data Consumers use the data and help define what they need from it.
• Data Owners have overall responsibility for a data domain and make sure agreed requirements are being met.
• Data Providers maintain the individual records and provide the real-world knowledge needed to keep them accurate.

Data providers may also be described as data stewards, record owners, CMDB librarians, data custodians, or similar roles depending on the organization.

The title matters less than the responsibility.

The important question is:

Who knows whether this specific record is correct, and who can provide the information needed to maintain it?

ServiceNow's own data-governance guidance makes a similar distinction between accountable Data Owners and operational Data Stewards who manage data according to agreed standards on a day-to-day basis. ServiceNow's Data Governance guidance provides more detail on these roles.

Data providers exist far beyond the CMDB team

A common mistake is to think of data providers only as configuration managers or technical CMDB specialists.

In practice, the role can exist almost anywhere in the organization.

For example:

Application owners and service managers

An application owner may only be responsible for a small number of applications, but they are often the person who knows which services belong to those applications, who supports them, and whether the information is current.

Infrastructure teams

A server team lead may be responsible for hundreds or thousands of virtual machines and understand the technical context around those records better than a central CMDB team.

HR and foundation-data owners

An HR coordinator may know whether employees are assigned to the right departments, business units, or cost centers.

Project managers

If project information is maintained in ServiceNow, project managers become providers of that data.

The same principle applies across the platform.

Data quality is not only a CMDB responsibility because the information being governed is not only CMDB data.

Some data providers may not work directly in ServiceNow

Not every provider maintains the record directly in the platform.

An HR coordinator, for example, may maintain employee information in another system that feeds ServiceNow through an integration.

Discovery can also be viewed as a data provider for infrastructure data.

But even where the immediate source is a system or integration, there are still people behind it.

Someone owns the source.

Someone understands why the information looks the way it does.

Someone needs to be involved if the incoming data repeatedly fails quality requirements.

That makes it useful to understand not only where the data comes from, but also who sits behind the source process.

Why organization-wide data quality targets often fail

A target such as:

“We need to reach 100% CSDM compliance.”

may sound ambitious, but it is difficult for an individual data provider to act on.

The same applies to a giant CMDB health score covering millions of records.

If one application owner improves ten records and the overall score barely moves, there is very little visible connection between their effort and the result.

That makes engagement difficult.

People are more likely to contribute when:

• The scope is understandable
• The requirements are realistic
• They can directly influence the result
• They can see their own progress

The challenge is therefore not only assigning responsibility.

It is designing targets that make sense to the person being asked to do the work.

Replace broad targets with personal data-quality targets

Instead of telling an application owner to align the entire CMDB with CSDM, give them a requirement that relates directly to their own applications.

For example:

Every Business Application you own should have the required Application Service relationship.

That is concrete.

It has a clear scope.

And the application owner can actually do something about it.

The same principle can be used for other domains.

A group manager might be responsible for making sure their groups have:

• A valid manager
• The minimum number of members
• The required roles

A location owner might be asked to ensure the sites they manage have:

• The correct location type
• A city or parent location
• A responsible contact or Managed by Group

The overall data-quality model can still be broad.

The individual experience should not be.

Start with a smaller CSDM scope

The same principle applies to CSDM.

Trying to achieve every possible CSDM requirement across the whole ServiceNow environment at once is difficult to turn into practical work.

Instead, requirements can be divided into smaller maturity stages or specific data domains.

For an application owner, an early goal might be limited to ensuring that Business Applications have the required Application Service relationships and other minimum Crawl-stage information.

Once that baseline is working, additional requirements can be introduced.

This gives people a sequence of achievable targets rather than one distant transformation goal.

Use critical records as the first manageable scope

Even a well-defined requirement may still apply to too many records initially.

One way to narrow the scope further is to begin with the most important records.

For example:

• Critical Business Applications
• Business-critical services
• High-priority infrastructure
• Locations used by key operational processes

Once that smaller group reaches the desired standard, teams can expand the scope.

This creates visible progress early.

It also gives the organization a chance to refine the process before applying it to thousands of records.

Personal scores make progress visible

One of the strongest ideas demonstrated in the session is giving each data provider a view of their own data-quality results.

Instead of looking at an enterprise-wide CMDB score, an application owner sees the records they are responsible for.

They can see:

• Their current compliance score
• How the score has changed over time
• Which of their records still have issues
• Which requirements are failing

That makes improvement much more tangible.

If someone fixes three of their fourteen applications, their own result changes.

They can see that their work had an impact.

This is very different from improving a few records inside a CMDB containing millions of CIs and seeing almost no movement in the global metric.

Use the domain owner view to focus follow-up

Personalization also benefits the person with overall responsibility.

In the demo, the Business Application domain owner can see the overall quality of the domain and then drill down by individual data provider.

That makes follow-up more targeted.

Instead of sending the same data-quality reminder to every application owner, the domain owner can see:

• Who has already reached the target
• Who still has unresolved records
• Which problems are affecting each person's data
• Whether their results are improving over time

This helps avoid unnecessary communication with people whose data is already in good shape.

It also gives the domain owner something much more specific to discuss with the people who still need support.

Do not require data providers to understand the CMDB data model

The people with the best knowledge of the data are not always the people with the best knowledge of ServiceNow.

That is especially true for application managers, business users, HR teams, and other non-platform roles.

The session demonstrates this with a missing Application Service relationship.

The application owner needs to know which Application Services belong to their Business Application.

They should not necessarily need to know:

• The underlying CMDB table structure
• The direction of the CI relationship
• The correct relationship type
• The Blueprint configuration

Those are modeling decisions that can be defined centrally.

The provider's job is to supply the correct real-world information.

Make remediation a simple decision, not a technical task

In the Data Quality Workspace demonstrated in the video, the provider sees only the records and findings assigned to them.

For example, an application owner may see that:

• The Application Type is missing
• A required Application Service relationship does not exist

The remediation experience asks the provider to supply the missing information.

They select the Application Type.

Or they identify the correct Application Services.

The Blueprint in the background handles how those selections translate into ServiceNow data.

This creates a useful separation:

The data-quality model defines what is required.

The provider supplies the information they actually know.

The DCM Data Quality Workspace is designed around this personalized approach.

Increase the requirements when people reach the first target

The session also demonstrates what happens after the initial requirements have been met.

Instead of trying to define the perfect data model from day one, the domain owner can add another requirement later.

In the demo, Department is added as a mandatory requirement for Business Applications.

The Blueprint is republished and the audit runs again.

Immediately, the new requirement appears:

• At domain level as a new problem area
• In each provider's personal results where it applies
• As a remediation action in the provider workspace

This demonstrates a more sustainable improvement model.

Reach one target.

Then introduce the next meaningful requirement.

Use the same model for different ServiceNow data domains

The approach is not limited to Business Applications.

The demo also applies the same idea to other data types.

User groups

A Group Blueprint can define requirements such as:

• Every group has a manager
• Every group has enough members
• Required roles are assigned

The group manager can then become the data provider responsible for those records.

Locations

A Location Blueprint can define a hierarchy from sites to cities, countries, provinces, and regions.

Responsibility can be assigned to contacts or Managed by Groups.

The same basic workflow still applies:

1. Define what good data looks like.
2. Run the audit.
3. Identify the responsible providers.
4. Show each provider only their own gaps.
5. Give them a simple way to correct the data.

That consistency makes it easier to scale the operating model across different parts of ServiceNow.

Engage data providers by measuring what they can influence

The central lesson from the session is straightforward:

People are more likely to engage with data quality when they are measured on things they can actually change.

A global CMDB score is important for governance.

It is not necessarily a useful personal target.

For the individual provider, a better experience is:

1. Show me the records I am responsible for.
2. Tell me exactly what is wrong.
3. Explain what information is required.
4. Give me a simple way to fix it.
5. Show me that my result improved.

That creates a much clearer connection between responsibility, action, and progress.

Create a success snowball instead of one large clean-up campaign

Small targets can also help build momentum.

Start with a manageable set of requirements and records.

Reach the target.

Make the improvement visible.

Then add the next requirement or expand the scope.

That creates what the session describes as a success snowball: people experience achievable progress instead of being presented with a permanent list of impossible data-quality problems.

The eventual ambition can still be high.

The path to reaching it becomes much more practical.

Related resources

• DCM Data Quality Workspace – see how personalized workspaces help data providers focus on their own records and remediation tasks.
• How to Establish Ownership in Your CMDB – a deeper look at the Consumer–Owner–Provider model and how ownership can be distributed.
• Why Ignoring Data Consumers Is a Big Mistake – why useful data-quality requirements need to start with how the data is actually consumed.
• 5 Challenges to Address for Better CMDB Data Quality – common organizational and practical barriers to improving CMDB data.
• CMDB Data Quality Playbook – a broader framework for ownership, data providers, remediation, and continuous improvement.