Problem
Location data in ServiceNow tends to drift: sites get created without a city or country attached, contacts and owning groups go stale, and planned or retired sites blend in with the ones actually operating. Location data is often maintained outside ServiceNow and potentially in multiple different data sources.
CSDM doesn’t define a single out-of-the-box model for locations, so teams are left to decide for themselves how sites, cities, states, countries, and regions should connect — and inconsistent choices break service mapping, asset assignment, and reporting the moment two teams model it differently.
All this creates issues for:
- Foundation data quality (duplicate or fragmented location records),
- Service mapping (inability to trace services to physical sites), and
- Operational processes (incorrect assignment of users or assets).
By introducing a clear hierarchical model, this blueprint ensures locations are properly structured and governed, avoiding ambiguity in ownership or reporting.
What the Blueprint Includes
The model starts from Location (Site) — the record every service, asset, and user actually locates against — and builds the geographic hierarchy and accountability around it. A City can roll up through a State/Province or connect directly to a Country, so the model flexes for both federal and non-federal geographies.
- Location (Site) – Root entity representing the operational site (an office, plant, data center, etc.). The blueprint scopes it to sites that are Operational, so planned or retired sites don’t dilute the model.
- Location (City) – The city the site belongs to.
- Location (State/Province) – The state or province the city belongs to, where that level of geography applies.
- Location (Country) – The country the state/province belongs to, or the city directly, in countries without a state/province level.
- Location (Region) – The continent or multi-country region the country belongs to.
- Company – The company associated with the site.
- User – The active contact accountable for the site.
- Group – The active group that manages the site (Managed by Group).
Considerations
Getting the most out of this blueprint means populating both the geography and the accountability side of every site, and being deliberate about which parts of the hierarchy your organization actually needs.
- Only Operational sites are in scope. The root condition filters Location (Site) to Life Cycle Stage = Operational, so keep that field current — a site stuck in Draft or Retired won’t appear in the model until its lifecycle status is set correctly. You might want to include sites without a Life Cycle or Location Type values, so that those are included after defining the proper Life Cycle Stage, Status and Location Type values that are included in the field setup.
- Populate both accountability fields with active records. Contact and Managed by Group should each resolve to an active User and an active Group — stale or empty values are the most common reason a site can’t be traced back to a real owner.
- Choose the City path deliberately. The blueprint includes an Alternative Link Group (“Location (City) Alternative”): a City can connect to its Country either through a State/Province or directly, whichever matches the geography you’re modeling.
- This version stops at the Site. Earlier versions of this blueprint extended below the Site to sub-site locations; this version intentionally removes that layer to keep the model focused on Site-and-above governance. Common data tables like Building belong below the Site and can be modeled separately.
- Start from the Site and grow outward. Get Site-level ownership and geography clean first, then extend into Building or other sub-site detail only where your organization actually needs it.
Benefits
A well-maintained Location hierarchy turns scattered site records into a governed structure that the rest of the platform can trust.
- Clear accountability. Every Site carries a Company, an active Contact, and an owning Group, so there’s always someone to ask.
- A single source of truth for locations. Site, City, State/Province, Country, and Region roll up consistently instead of being modeled ad hoc by different teams.
- Lifecycle-aware scope. Filtering the model to Operational sites keeps planned and retired locations from cluttering reporting and service mapping.
- Flexible geography. The alternative City-to-Country path supports both federal and non-federal countries without extra customization.
- A stable foundation to build on. With Site-and-above governed, Building and other sub-site detail can be layered in later without reworking the core model.
Related Information
Find more blueprint templates related to Foundation Data.
How to Get This Blueprint?
If you’re already a Data Content Manager Customer, you can download the Blueprint from the Knowledge Base. You will need your login credentials to access the blueprint download page.
