CIS‑DF Blueprint
A field reference for the Certified Implementation Specialist — Data Foundations exam, drawn from the full objective blueprint and the verified question set behind it.
Official Exam Blueprint
Verbatim from ServiceNow’s published CIS‑DF exam blueprint — the five domains and their objectives, exactly as tested.
| # | Domain | Exam Objectives | % |
|---|---|---|---|
| 1 | Configuration |
Given a scenario:
|
15% |
| 2 | Ingest |
Given a scenario:
|
19% |
| 3 | Govern |
Given a scenario:
|
35% |
| 4 | Insight |
Given a scenario:
|
20% |
| 5 | CSDM Fundamentals |
Given a scenario:
|
11% |
| Total | 100% | ||
Everything in this exam sits on top of one idea: a ServiceNow CMDB is only useful if the data in it is trustworthy, and trustworthiness isn’t an accident — it’s the output of three disciplines working together. ServiceNow calls them the three pillars of Data Foundations, and almost every domain on the blueprint is really just one of these three pillars viewed from a different angle:
Getting CI data into the CMDB accurately — Discovery, Service Graph Connectors, Import Sets, Agent Client Collector, and how Asset and CI records stay in sync.
Keeping that data trustworthy over time — ownership, health metrics, deduplication, lifecycle policy, and the CMDB Workspace tools that enforce it.
Getting value back out — dashboards, Unified Map, Natural Language Query, and the playbooks that turn a health score into a fix.
Configuration is the mechanical layer underneath all three (CI Class Manager, the Identification & Reconciliation Engine, Multisource CMDB), and CSDM Fundamentals is the naming and modeling standard that keeps Ingest, Govern, and Insight all describing the same underlying reality the same way. Read Govern first if you only have time for one domain — it’s more than a third of the exam by itself.
Configuration
CI Class Manager — table, class attributes, hierarchy
CI Class Manager is the administrative home for the CMDB’s class hierarchy. Every CI class extends cmdb_ci (directly or through a parent class), and CI Class Manager is where you view that hierarchy, create or extend classes, manage class-level attributes, and set an icon per class — each of those specific actions lives on its own tab (Class Hierarchy Tree, Attributes, Basic Info) rather than being scattered across generic platform screens.
- Principal Class is set on the Basic Info tab. A Principal Class is a class flagged as significant enough to appear by default in class-scoped filters and pickers elsewhere in the platform; adding or removing classes from that filter for something like IoT devices requires the
sn_cmdb_adminrole pluspersonalize_dictionary, since it’s editing dictionary-level metadata, not a simple CMDB record. - Pinned Classes lets a CI Class Owner bookmark the specific classes they manage so they surface at the top of the class list — the actual answer to “quickly get back to a class I manage often,” not a fabricated “CI Favorites” feature.
- Changing a class icon is done on the same Basic Info tab where Principal Class lives.
The Identification & Reconciliation Engine (IRE)
Every CI insert or update from Discovery, Import Sets, or an SGC passes through the IRE, which answers two separate questions in sequence:
- Identification — is this incoming payload a brand-new CI, or does it match one that already exists? This is governed by Identification Rules, made up of one or more identifier entries, each with a priority and a set of criterion attributes. The IRE evaluates entries strictly in priority order and stops at the first one whose criteria produce a match — it does not check every entry and pick the best one.
- Reconciliation — once a CI is identified, which data source is allowed to win when two sources disagree on a field’s value? This is governed by Reconciliation Rules, which control updates to an existing CI’s attributes — they have no say over whether a new CI gets inserted (that’s identification’s job) and no role in deletion or read access.
Preventing an untrusted source from inserting new CIs: an IRE Data Source Rule is the specific mechanism that blocks a named discovery source from inserting new CIs of a class, while optionally still letting it update existing ones. This is a different tool from a reconciliation rule (which only arbitrates already-existing data) and different from an identification rule (which decides "same CI or new CI," not "is this source allowed to write at all").
Preventing IRE-bypass duplicates from import sets: set coalesce on the transform map’s field mappings so it searches for a match before inserting. For data that specifically needs to be CMDB-identified through the IRE from a legacy transform map, the onBefore script must call the CMDBTransformUtil API (setting discovery source and calling identifyAndReconcile) — onStart fires before any row data is available and onComplete/onAfter fire too late to control insert-vs-update.
CMDB 360 / Multisource CMDB
Multisource CMDB is off by default — it retains every source’s raw per-attribute payload, which has real storage and performance cost, so activating it is deliberate. It requires both: installing the ITOM Discovery License plugin and setting glide.identification_engine.multisource_enabled to true. It is a prerequisite for dynamic reconciliation rules (like “largest value” or “most reported”) to function — without it, the IRE only ever has one static winning value to work with, nothing to compare.
| Property | Controls |
|---|---|
glide.identification_engine.multisource_enabled | Master switch — turns Multisource CMDB on at all |
glide.identification_engine.multisource_cmdb_ci_enabled | Payload capture for CIs on classes that do extend cmdb_ci |
glide.identification_engine.multisource_non_cmdb_ci_enabled | Payload capture for CIs on classes that do not extend cmdb_ci |
glide.cmdb.logger.source.cmdb_multisource | Diagnostic logging for multisource processing |
glide.identification_engine.multisource.recompute.max.ci.limit | Caps CIs processed per recompute batch |
CMDB 360 Saved Queries are viewed and created in the Saved queries window on the CMDB 360 tab of CMDB Workspace — not in CMDB Query Builder (a different, relationship-query tool) and not on any “CMDB Health tab.”
Ingest
The four ingestion methods, and when to use each
| Method | Model | Best for |
|---|---|---|
| ServiceNow Discovery | Agentless, horizontal | Auto-identifying devices/apps across the network via credentialed probes (MID Server). The base inventory layer. |
| Agent Client Collector (ACC) | Agent-based | Lightweight, continuous real-time endpoint config visibility — the only agent-based option of the four. |
| Service Graph Connector (SGC) | Vendor-maintained, pre-built | Third-party integrations that need to minimize technical debt — built and kept current by ServiceNow/a partner, not your own team. |
| Import Sets + Transform Maps | Self-built | Data sources with no SGC available; you own the ongoing mapping/maintenance burden. |
Service Mapping is a fifth, deeper capability — it goes past flat inventory to trace a specific business service’s actual components and relationships. Within Service Mapping, Top-Down Mapping (pattern-based, most granular, for mission-critical/on-prem/legacy) and Connection Suggestion (an ML assist that reviews/confirms relationships Top-Down finds) are used together, not as competing alternatives. The technique actually built for cloud-native/container/dynamically-scaling environments is a separate one: Tag-based Mapping.
Minimizing technical debt on an ongoing integration: favor an IntegrationHub Spoke / Flow Designer over hand-written script includes and business rules — spokes are maintained through ServiceNow’s own upgrade cycle, while custom scripts routinely break when a vendor API or platform release changes underneath them.
Service Graph Connectors, in more detail
SGC connectors in the Store are organized into categories including Cloud (AWS, Azure…) and Observability (Datadog, Dynatrace…), plus ITOM/ITSM and Network groupings. The exam repeatedly tests the negative side of this: “DevOps,” “Workflow Automation,” and “Robotic Process Automation (RPA)” are NOT SGC categories — DevOps toolchain data typically comes in through IntegrationHub instead, and RPA is an unrelated ServiceNow product line. If a question offers Cloud/Observability alongside one of those three fakes, the fakes are always wrong.
After installing the Service Graph Connector Central plugin, the new SGC Central tab appears inside CMDB Workspace. If you customize an installed SGC’s field mappings, that customization is your responsibility to maintain through future connector updates — it doesn’t get a special protected tag or an auto-forked “custom” version.
Asset & CI alignment
Asset and CI records stay in sync through a handful of specific, named mechanisms — this is one of the most concretely-testable objectives on the blueprint:
- A CI created from an Asset without going through Discovery gets
Discovery source = SNAssetManagement— the direct way to filter a report for “created from an asset, never actually discovered.” - An Asset’s State field syncs to the CI’s Install Status (non-hardware CIs) or Hardware Status (hardware CIs, which takes precedence) — the mapping is logical, not one-to-one by name (e.g. “In Stock – Pending Disposal” → CI “In Disposition”). Sync only happens once the Asset and CI records actually point at each other.
- “Assigned to” on an endpoint CI does not auto-sync back to the Asset the same way State does — that direction needs an explicit sync action, not a passive field mapping.
- When CI Class Manager sets Managed by Group at the class level and a Technology Management Offering (formerly Technical Service Offering) also sets Managed by Group (and Change Group) for that class’s dynamic CI group — the Technology Management Offering wins, via the CSDM – Sync Group Attributes business rule cascading down to every CI in that offering’s dynamic CI group.
Non-discoverable data & regulatory tracking
Attributes with no on-host footprint — a warranty expiration date is the classic example — can never be found by Discovery no matter how it’s configured, because the data doesn’t exist on the device’s OS or firmware at all; it lives only in an external system like a vendor portal. The fix is a scheduled import (Import Set/Transform Map, or an SGC where a vendor connector exists) pulling that external data on a recurring cadence.
For tracking regulatory/security compliance identifiers against CSDM objects, the relevant artifact is the Information Object — it describes a logical category of data (PII, PCI, etc.) and links it to the Business Application(s) that create, store, or process it, which is exactly the traceability GDPR/PCI-DSS style requirements need.
Govern
More than a third of the exam. This sheet alone is worth close, careful reading.
The CMDB Health score: 6 metrics under 3 KPIs
| KPI | Sub-metrics | Answers the question… |
|---|---|---|
| Completeness | Required, Recommended (fields) | Are your CIs populated with the necessary data? |
| Correctness | Duplicates, Staleness, Orphans | Are your CIs accurate, current, and minimally duplicated? |
| Compliance | Audits (desired-state / scripted) | Are your CIs configured as expected? |
- Required vs. Recommended fields: Required fields block record creation/update when empty, are enforced globally, controlled by
glide.required.attribute.enabled, ideally auto-populated, and IRE identification-criterion fields are treated as Required. Recommended fields are the unenforced, lower-stakes tier and a safe testing ground before promoting a field to Required. - Staleness rules ship pre-configured — the base
cmdb_ciclass has a default effective duration of 60 days, inherited by every child class (overridable per class in CI Class Manager). Orphan rules are the opposite: a base system ships with zero — an administrator must manually create every orphan rule for whichever classes/relationships they want evaluated (e.g. flagging a Computer with no owner, or a Disk with no Contains/Contained-by relationship). The two rule types are entirely independent and configured on separate tables; don’t assume Orphan inherits anything from Staleness. - Desired-state audits feed the Compliance scorecard by comparing a CI’s actual configuration against an expected baseline.
Duplicates: causes, detection, and remediation
Duplicates typically arise from multiple discovery sources creating separate records for the same physical/logical asset, especially when identification rules can’t reliably match across sources. During Discovery, if a new CI is found and a duplicate already exists, resolution depends on discovery-source population on the conflicting records — records without a discovery source populated are the ones flagged, records that both carry a populated discovery source are treated as a known, tracked condition rather than a fresh failure.
Two remediation paths, deliberately different in scale:
- De-Duplication Templates resolve matching duplicates in bulk, using rules you define once.
- Duplicate CI Remediator is a guided wizard for resolving duplicates one at a time. Per ServiceNow’s own documentation, the recommended Main CI is typically the one that’s oldest, has the most relationships, and was most recently updated.
- De-Duplication Tasks (assigned to a group to work) and the Correctness Scorecard (pure insight, no remediation of its own) round out the toolkit — know which of the four does which job, since exam questions like to swap these.
- Now Assist for CMDB layers AI detection/remediation on top of this by leveraging De-Duplication Templates.
De-duplication tasks generated from IRE-ingested data live in CMDB Workspace, under its de-duplication task area.
Reclassification: managing a CI’s attributes as its class changes
When Discovery or the IRE moves a CI to a different, more accurate class, that move is one of three governed reclassification behaviors, each gated by its own system property (default true — automatic and silent):
| Behavior | Property | Effect on attribute data |
|---|---|---|
| Upgrade — move to a more specific child class | glide.class.upgrade.enabled | No loss — the child class inherits every attribute the parent had |
| Downgrade — move to a less specific parent class | glide.class.downgrade.enabled | Can exclude data — attributes unique to the old, more specific class may not exist on the new one |
| Switch — move to an unrelated class | glide.class.switch.enabled | Can exclude data, same reason as Downgrade |
A reclassification task is generated only when the property governing that specific behavior is set to false for the scenario actually occurring — e.g. disabling glide.class.switch.enabled has no effect on an Upgrade scenario, since a different property governs it. With the relevant property false, the IRE can’t auto-reclassify and raises a task for manual review instead. “Promotion” isn’t a real IRE behavior; Merge (duplicate resolution) and Reparent (relationship hierarchy) are real CMDB concepts but neither is a reclassification behavior.
CMDB Data Manager
Data Manager governs a CI’s lifecycle end-to-end through configurable policies. Know the full policy set and don’t let a plausible-sounding fake crowd out a real one:
| Policy type | What it does |
|---|---|
| Retire | End-of-life; changes lifecycle status, record stays, restorable |
| Archive | End-of-life; removes from active table, recoverable for a defined period |
| Attestation | Confirms a CI still exists / is still accurate |
| Certification | Verifies field-level content/data quality on a CI |
| Delete | Permanent removal, no restoration path — kept separate from the softer Retire/Archive pairing |
Retire and Archive are specifically the two “end-of-life” types (both restorable/status-change, distinct from permanent Delete). Policy task assignment should use the Managed by Group field synced from CI Class Manager, so ownership routing stays consistent with class-level accountability. Tasks generated by Data Manager policies are reviewed in the Data Manager task queue itself — not folded into generic Change or Incident lists.
Operationalizing governance: roles, framework, and CMDB Workspace
The single most-tested “soft” idea in Govern: establishing clear governance and continuously monitoring CMDB health beats any purely technical fix. Maximizing data volume, relying solely on Discovery, letting teams edit freely, or centralizing every CI under one administrator are all distractors — none of them substitute for defined ownership plus ongoing measurement.
A CMDB governance framework is the documented combination of ownership assignments, data standards, Discovery/Data Source rule configuration, and recurring audit cadences — the structural container the roles below (and the Health Dashboard, and Data Manager policies) all fit inside. Filtering which CI classes appear on the Health Dashboard — e.g., excluding classes not yet ready for management — is done via a Health Inclusion Rule. A regional Configuration Manager who only sees an overall/by-class score gets a regionally-scoped view by creating a CMDB Group (type: health, scoped by region) — a Health Inclusion Rule is the wrong tool here, since it controls what counts globally rather than giving one manager a personal, region-scoped slice of the same dashboard.
| Role | Owns |
|---|---|
| CI Class Owner stored in Managed by Group | Accuracy, completeness, freshness of every CI record in their class |
| Data Steward | Day-to-day data work — creating, validating, correcting records |
| CMDB Process Owner | Overall CMDB strategy, health, and alignment to business goals |
The 3 pillars & the Data Foundations Dashboards
Recall from the intro: Ingest, Govern, Insight are the three pillars — Compliance/Completeness/Correctness are scorecards inside the Health Dashboard, not pillars themselves, and are an easy trap for anyone who’s only skimmed the dashboard UI.
The CMDB and CSDM Data Foundations Dashboards are obtained as a built-in ServiceNow feature (no separate install) and combine health metrics with a Result percentage and a Priority (1–Critical to 5–Low, the product of metric weight and severity). The color-coded Result bar uses Red <50% / Yellow 50–90% / Green >90%.
When two metrics compete for attention with equal business drivers, act on the higher Priority first, even if its Result percentage looks less alarming — priority already accounts for weight and severity together, so a 55% result at Priority 3 outranks a 20% result at Priority 4. Every metric’s Remediation Playbook URL links to a Now Support KB article structured the same way every time: Summary of the indicator → Overview of the problem → Importance of addressing it → Fix or Improve — what/why/how, in that order.
Insight
The business value of CMDB, across products
A single, well-governed CMDB is the shared substrate under most of ServiceNow’s portfolio, and each product draws a different kind of value from the same underlying CI and relationship data:
- ITSM — faster incident resolution and more accurate change-risk assessment, both driven by knowing a CI’s real dependencies before you act on it.
- ITOM — Service Mapping and event correlation depend entirely on CMDB relationship data being current and correctly modeled.
- SecOps — vulnerability response and incident containment need to know exactly which business services a compromised CI actually supports.
- ITAM — asset lifecycle tracking leans on the Asset–CI alignment covered on the Ingest sheet.
The connecting thread the exam cares about: none of this works without governed, trustworthy data underneath it — which is precisely why Govern is the largest domain on the blueprint. Industry research on failed CMDB initiatives points the same direction: most failures trace back to data quality and governance gaps, not a missing feature.
Unified Map & dependency visualization
Unified Map, inside CMDB Workspace, is the tool for visualizing how CIs connect — it consolidated what used to be separate Dependency Views and Service Mapping visualizations into one hierarchical, graphical map. Start from any CI and expand upstream/downstream, with real-time impact analysis built in.
Natural Language Query (Intelligent Search)
NLQ lives in CMDB Workspace and lets a user query the CMDB in plain English — no need to know class or table names. It corrects spelling, auto-detects whether the query spans one class or several, and offers a disambiguation step when a query could plausibly match more than one class (it never just floods you with every class’s results, and never demands exact table names). Configure Synonyms (NLQ > Synonyms) so equivalent terms like “laptop” and “notebook” return the same results.
CMDB 360 saved queries & the Query Builder
CMDB Query Builder constructs filtered, relationship-aware CI queries — e.g., finding all application services with a database that has open incidents, plus every piece of infrastructure inside those services, by chaining relationship steps in the builder rather than writing raw filters. CMDB 360 saved queries surface insight from the multisource payload data specifically (cross-source comparisons), distinct from a standard CMDB report.
Get Well Playbooks & dashboard business value
Every foundational metric’s playbook follows the same four-part structure covered on the Govern sheet. The business case for the dashboards themselves rests on turning raw health scores into prioritized, actionable work — better decision-making, faster incident/change impact assessment, and a documented path from “metric is red” to “metric is fixed,” rather than the dashboards being a passive reporting layer alone.
A Configuration Manager building out end-to-end service-modeling quality references the CSDM Data Foundations Dashboard specifically (maturity-stage metrics: Crawl / Walk / Run tracking app-to-service, technical-offering, and business-consumption modeling) — distinct from the CMDB Data Foundations Dashboard, which is scoped to CI-level data hygiene (serial numbers, duplicate locations, etc.).
CSDM Fundamentals
What CSDM is actually for
CSDM (Common Service Data Model) is a standard, shared set of service-related definitions and relationships across every ServiceNow product — it sits on top of the CMDB as a modeling discipline, it doesn’t replace it. The payoff: a single, consistent source of truth that supports accurate cross-product service-level reporting, end-to-end upstream/downstream visibility, and better-informed decisions — instead of every team inventing its own definition of “service” and none of those definitions rolling up together.
The seven-domain model & the Crawl–Walk–Run–Fly approach
ServiceNow deliberately recommends implementing CSDM in stages rather than modeling every domain at once — each stage validates a stable foundation before the next builds on it, which is exactly why Foundation data (locations, companies, users, groups, base CI classes) comes first, before any Technical Service, Business Service, or Application Service modeling begins.
That’s all seven CSDM 5.0 domains. Manage Portfolios is surfaced operationally through Digital Portfolio Management — a unified workspace for owners to manage portfolios, services, offerings, and products across the full Plan–Build–Run–Optimize lifecycle. It unites the older Service Portfolio Management and Application Portfolio Management concepts rather than sitting alongside them as a third option.
An Application Service [cmdb_ci_service_auto] is the deployed-instance representation — the logical stack-plus-dependencies record Discovery/Service Mapping trace. A Business Application [cmdb_ci_business_app] is deliberately the opposite: an abstract, business-facing concept with no tie to a specific environment. The Application Service Wizard is the tool that relates an existing Application Service to its Business Application(s) and Service Offering(s), building the correct CSDM relationships automatically.
Lifecycle fields & governance mapping
CSDM standardizes CI lifecycle tracking on two fields: Life Cycle Stage and Life Cycle Stage Status — meant to eventually replace the patchwork of class-specific legacy fields (Install Status, Operational Status, Hardware Status). Legacy values map into the new fields via the Life Cycle Mapping table, which is exactly where a governance team transitioning off legacy status fields would work.
Building out the Design & Planning domain’s components typically involves the Application Owner (knows the application’s purpose/lifecycle) and the Enterprise Architect (maps it to business capabilities and spots portfolio redundancy) — not the Business Relationship Manager, who operates further downstream in Service Consumption.
Roles & personas cheat-sheet
The exam leans hard on scenario questions that name a persona and ask what they’d do or which domain they work in. Business/governance personas and platform security roles are tested separately — don’t conflate the two.
Accountable for accuracy/completeness/freshness of one CI class’s records (Managed by Group).
Day-to-day CI record creation, validation, correction.
Overall CMDB strategy, health, business alignment.
Day-to-day CMDB administration — the default “who’s doing this” persona in scenario questions.
Design & Planning domain — capability mapping, redundancy, investment roadmap.
Design & Planning — owns an application’s purpose and lifecycle.
Service Consumption — Service Portfolio Management, offerings to business consumers.
Service Delivery / Build & Integration — owns a technical service or application service instance.
| Role | Grants |
|---|---|
| sn_cmdb_admin | CMDB & CI Class Manager administrative actions |
| personalize_dictionary | Editing dictionary-level metadata (e.g. Principal Class filters) |
| cmdb_query_builder | Build/run CMDB Query Builder queries only — no dictionary or class-config privilege |
| sn_csdm_admin | CSDM domain-model configuration (service models, domain mappings) |
| discovery_admin | Discovery administration |
| itil | Standard ITSM record access |
Tool disambiguation table
The exam frequently offers 4–6 real ServiceNow tool names as options and asks which one specifically does a job. Sort them mentally by what they actually touch — and by how you’d actually click your way there, since the exam also tests navigation directly.
| Tool | Actually does | Navigate via |
|---|---|---|
| CI Class Manager | Class hierarchy, attributes, icons, Principal Class, Pinned Classes | All › Configuration › CI Class Manager |
| CMDB Workspace | General CMDB browsing/admin home — hosts Unified Map, NLQ, SGC Central, de-dup tasks | Workspaces › CMDB Workspace |
| Unified Map | Visualize CI-to-CI relationships (replaces old Dependency Views + Service Mapping views) | CMDB Workspace › Home › Quick Links › Unified Map (or from any CI’s related items) |
| CMDB Query Builder | Build filtered, relationship-chained CI queries | All › Configuration › CMDB Query Builder |
| CMDB Health Dashboard | Correctness/Compliance/Completeness scorecards | All › Configuration › CMDB Health Dashboard or CMDB Workspace › Home › Quick Links |
| Health Preference (enable Health jobs) | Turns on the scheduled jobs that populate the Health Dashboard — disabled by default | All › Configuration › Health Preference › Scheduled Jobs |
| CMDB / CSDM Data Foundations Dashboard | Good-practice adherence + Get Well Playbooks; CSDM version tracks maturity stage | CMDB Workspace › Home › Quick Links |
| CMDB Data Manager | Lifecycle policies — Retire, Archive, Attestation, Certification, Delete | CMDB Workspace › Management › Management tools › Manage › Data Manager |
| CMDB Groups | Arbitrary dynamic scoping (region, type…) with its own dedicated Health score — not the same as a Health Inclusion Rule | Nav filter › CMDB Groups |
| Health Inclusion Rule | Globally excludes CIs of a class from Health Dashboard calculations entirely | CI Class Manager › select a class › Health tab |
| Identification / Reconciliation Rules | Per-class IRE matching & update-arbitration config | CI Class Manager › select a class › Identification Rule / Reconciliation Rules tab |
| Duplicate CI Remediator | Guided, one-at-a-time duplicate resolution wizard | CMDB Workspace › Home › Important actions tile › open a de-duplication task |
| De-Duplication Templates | Bulk duplicate resolution via predefined rules | Nav filter › De-Duplication Template |
| Service Builder | Guided creation of Business/Technical Services & Offerings | Nav filter › Service Builder (also linked from Service Portfolio Management) |
| Application Service Wizard | Relate an existing Application Service to offerings/business apps | Open an existing Application Service record › Related Links › launch the wizard (not a standalone menu item) |
| Digital Portfolio Management | Ongoing portfolio/offering/product lifecycle management | Workspaces picker › Digital Portfolio Management |
| Import Sets / Transform Maps | Load external data into a staging table, then map it to a target table | All › System Import Sets › Load Data / Transform Maps |
Paths marked “Nav filter” are ones no single confirmed menu breadcrumb could be verified for — type the name directly into the Application Navigator’s filter box, which always works regardless of exact module placement.
Known trap questions
Every item below is a real correction made while building and verifying this exam bank against ServiceNow’s own documentation — each one looked plausible enough to ship until it was checked against a primary source.
- Application–Server relationship type is Runs on::Runs, not Runs::Runs On.
- “How CIs connect” in CMDB Workspace is Unified Map — there is no separate “Relationship Map” tool.
- CSDM Sync Group Attributes syncs Support Group, Change Group, and Managed by Group — not “Assignment Group.”
- Data Foundations Dashboard color thresholds are Red<50% / Yellow 50–90% / Green>90% — confirmed against ServiceNow’s own documentation, not 40/80.
- Connection Suggestion vs. Top-Down Mapping are used together, not chosen between by environment — Tag-based Mapping is the real cloud/container answer.