Build location data that supports change and governance

Location data in ServiceNow: build a hierarchy you can actually govern

Location data sits quietly underneath a surprising number of ServiceNow processes. Users, groups, hardware, configuration items, services, organisational structures, and operational workflows can all depend on knowing where something or someone is located.

When location data in ServiceNow is inconsistent, incomplete, or structured differently across teams, those dependencies become harder to trust. A device may point to a location that is no longer operational. A site may exist without a clear owner. Countries, cities, buildings, and sites may be represented differently across different parts of the organisation.

The problem is therefore not simply whether the Location field contains a value. The underlying records need a structure that people understand and can maintain.

In this Blueprint Live session, Mikko uses the Locations – Hierarchy Starting from Sites Blueprint to demonstrate how a practical ServiceNow location hierarchy can be defined, audited against live data, assigned to responsible owners, and improved over time.

Why location data matters beyond the location table

Locations are part of ServiceNow foundation data, which means their value comes largely from all the other data and processes that depend on them.

Reliable location data can help teams:

• Understand where users, devices, servers, and other configuration items are located
• Support processes such as on-site support and asset management
• Validate that records point to locations that are still operational
• Create more consistent reporting across sites, cities, countries, and regions
• Clarify responsibility for maintaining location records
• Give services and operational processes dependable geographic context
• Support governance and regulatory use cases where the location of services, suppliers, people, or infrastructure matters

The challenge is therefore not simply filling in the Location field.

The underlying location records themselves need enough structure and ownership to be trusted by everything that references them.

Location data is one example of why strong foundation data in ServiceNow matters across the wider platform. The How to Improve Foundation Data with Examples guide explores the same principle across users, groups, organizations, and other shared data.

Location quality also affects the configuration items that depend on it. A server, for example, may have technically complete infrastructure data while still pointing to an inappropriate or outdated location. If you are working on the wider service context around infrastructure, the Server Relationships in ServiceNow Blueprint Live recording looks at the same principle from the server and CSDM relationship perspective.

Build a ServiceNow location hierarchy from the level you actually use

ServiceNow treats locations as part of the CSDM Foundation domain and provides attributes such as Location type, Managed by group, lifecycle information, source, and validation fields to support the management of location data. Its location types can also be used to build a hierarchy covering levels such as regions, states or provinces, cities, sites, buildings, floors, and rooms.

You can see these fields and the wider role of locations in the official ServiceNow CSDM Foundation domain documentation.

In the session, the example DCM Blueprint starts with sites and then connects them through a geographic hierarchy:

Site → City → State or Province → Country → Region

The exact structure will depend on the organization. A company operating in one country may not need every layer, while a global organization may need states, provinces, regions, or additional levels.

The important part is to define what each record represents.

A useful starting point is therefore the location type. Instead of treating every location as an interchangeable record, identify whether it represents a site, city, country, region, building, floor, or another level relevant to your organization.

From there, you can decide which relationships are actually necessary.

If most operational records in ServiceNow refer directly to sites, start by making those site records trustworthy. The rest of the hierarchy can be introduced or refined as the need becomes clearer.

Establish location ownership before trying to clean everything

One of the strongest themes in the session is that data quality improvement should begin with responsibility.

Finding hundreds of incomplete location records is useful. Finding hundreds of incomplete records without knowing who should fix them is much less useful.

A practical location model should therefore define who is responsible for maintaining each record. In the Blueprint demonstrated in the webinar, this can include a contact and a Managed by group.

Once those responsibilities are available, audit findings can be routed to the appropriate people rather than becoming another centralised clean-up project for the ServiceNow or CMDB team.

This also changes how you approach an existing location-data problem.

Instead of asking:

“How do we clean our entire location table?”

you can ask:

“Which locations belong to this team, and what is the minimum information we need them to maintain?”

That creates a much more manageable starting point.

The same principle is central to DCM’s broader approach to data quality: establish the data domain, identify the people who can provide the correct information, define measurable requirements, and expand from there. You can see the wider approach in 5 Steps to Better Data Quality.

Define different requirements for different location types

Not every location should have exactly the same requirements.

A physical site may need:

• A location type
• Lifecycle information
• A street address
• A contact
• A Managed by group
• A parent city or geographic relationship

A country or region record clearly does not need all of those same fields.

DCM Blueprints can make those requirements conditional. In the webinar example, street information is required for relevant physical location types such as sites and buildings, without forcing the same requirement onto cities, countries, or regions.

This is useful because a generic completeness score can otherwise be misleading. The question is not whether every field has a value.

The better question is whether each type of location has the information that your organisation has decided it needs.

Audit the location data you already have

Once the requirements are defined, the next step is to compare them with the records already in ServiceNow.

The audit shown in the session exposes problems such as:

• Missing contacts
• Missing Managed by groups
• Missing lifecycle information
• Incomplete location hierarchies
• Incorrect or missing location types
• Other required attributes that do not meet the Blueprint

This gives the team responsible for the overall location domain a measurable view of where the largest gaps are.

More importantly, it helps establish an order of operations.

If large numbers of locations do not have an accountable contact or group, ownership may need to be addressed before asking people to resolve all of the other findings.

Once ownership exists, individual data providers can work through the records they are responsible for rather than receiving a generic list of problems covering the entire organisation.

Location data does not have to be maintained in one system

Large organisations often have several sources of location data.

Site information might be maintained directly in ServiceNow, while cities, countries, or geographic reference data come from another trusted system. Different location types may therefore have different systems of record and different maintenance processes.

That does not prevent you from auditing the resulting data in ServiceNow.

The session demonstrates how DCM remediation tasks can be used to tell people what needs attention even when the actual correction has to take place somewhere else.

For example, a task can identify a problematic ServiceNow location record while instructing the responsible person to update the source system instead. Once the corrected information reaches ServiceNow and the next audit no longer detects the issue, the finding can be resolved.

This allows governance and measurement to remain consistent without pretending that every piece of data originates in the same place.

Use location data to validate the records that depend on it

Improving the location table is only part of the value.

Once location data has a dependable structure, other Blueprints can validate the way it is being used.

The webinar gives the example of personal computers. Instead of checking only whether a PC has some location value, you can ask more meaningful questions:

• Does every PC have a location?
• Is that location the correct type, such as a site?
• Is the referenced location still operational?

This prevents a technically populated Location field from being treated as good data when the underlying reference is inappropriate or outdated.

The same principle can extend to other configuration items, users, services, organisational structures, and processes that depend on location information.

Start with location types, responsibility, and a manageable scope

If your existing ServiceNow location data is messy, the answer does not have to be a global clean-up project.

A more practical approach is to start with:

1. The location level you use most, such as sites
2. A clear location type for those records
3. Named people or groups responsible for maintaining them
4. A small set of minimum requirements
5. A measurable group of records, such as one country, business unit, or responsible team

Once that baseline is working, you can expand the hierarchy, introduce additional rules, and bring more location types into scope.

This follows the same approach used across the DCM Blueprint Library: define what good data looks like, audit against that model, engage the people who know the data, and improve it progressively.

Keep location data from becoming inconsistent again

A one-time clean-up does not create trustworthy foundation data.

Locations change. Offices close. New sites open. Responsibility moves between teams. Records that were correct twelve months ago may no longer reflect reality.

That means location data needs both continuous auditing and, where appropriate, periodic certification.

An automated audit can continually detect records that no longer meet the defined rules. Certification adds a different kind of validation: asking accountable people to periodically confirm information that cannot be proven through automated checks alone.

For example, a yearly certification might ask someone responsible for a site to confirm that the location is still operational and that its lifecycle information remains correct.

Together, regular auditing and periodic human validation help turn location-data quality into an ongoing process rather than another clean-up exercise.

Related resources

If you are working on foundation data, CSDM, or location governance in ServiceNow, these resources may also help:

• How to Improve Foundation Data with Examples – why locations, users, groups, and organisational structures form an important shared foundation for ServiceNow processes.
• 5 Steps to Better Data Quality – a practical model for establishing ownership, defining requirements, auditing data, and improving it progressively.
• Server Relationships in ServiceNow – see how infrastructure records can be connected to the services and operational context around them.