⬡ Part 7 · Topic 5
CMDB Workspace & Natural Language Query — Making CMDB Data Accessible to Everyone
All the configuration data in the world is worthless if users can't access it without writing complex database queries. CMDB Workspace is ServiceNow's modern interface for exploring CI data — and Natural Language Query (NLQ) lets users ask questions in plain English instead of filter conditions. Together with the CI 360 view, they transform the CMDB from a technical repository into a usable operational tool.
Section 1
CMDB Workspace — The Modern CMDB Interface
Before CMDB Workspace, exploring the CMDB meant navigating to specific tables (cmdb_ci, cmdb_ci_server, etc.), building filter conditions manually, and having enough technical knowledge to know which table held which data. CMDB Workspace changes this by providing a unified, visual starting point for all CMDB exploration.
Navigate to Configuration → CMDB Workspace.
What CMDB Workspace Provides
- Unified search across all CI classes: Type a hostname, IP address, or application name and get results from every relevant table — no need to know whether the CI is in cmdb_ci_server, cmdb_ci_linux_server, or cmdb_ci_vm_instance.
- CI 360 View: Clicking any CI opens a comprehensive view of that CI's data, relationships, health, source attribution, and linked ITSM records (incidents, changes, problems) in one screen.
- Natural Language Query (NLQ): Ask questions in plain English. ServiceNow translates the question into a structured CMDB query automatically.
- CMDB Health integration: Health scores are surfaced in the Workspace so users can see data quality context alongside CI data.
- Relationship visualization: Navigate from a CI to its connected CIs through the relationship map without writing queries.
Analogy — CMDB Workspace as a Search Engine for IT Infrastructure
Old CMDB access was like using a library catalogue where you had to know the Dewey
Decimal number to find a book. CMDB Workspace is like Google — type what you're
looking for and get relevant results, regardless of which internal "section" it's stored in.
NLQ goes further: instead of keywords, you can ask full questions — like asking a librarian.
Section 2
Natural Language Query (NLQ) — Asking the CMDB Questions in Plain English
Natural Language Query (NLQ) allows users to type questions in conversational English and get structured CMDB results without knowing filter syntax or table names. ServiceNow's NLQ engine translates the plain-English question into a GlideRecord query behind the scenes.
Example NLQ Queries
- "Show me all Linux servers in the Production environment"
- "Which servers were discovered in the last 7 days?"
- "Find all CIs owned by the database team with an incident in the past month"
- "List cloud VMs running in us-east-1 with more than 8 CPUs"
- "Which applications depend on the Oracle database PROD-ORA-01?"
NLQ translates these into structured queries against the CMDB tables and returns a list view of matching CIs. The generated query is also visible so technically skilled users can verify or refine it.
NLQ Limitations (Important for Exam)
- NLQ works best with well-populated, consistent data. If field values are inconsistent (mix of "Production" and "Prod" and "PROD" for the environment field), NLQ may miss records. Data quality directly affects NLQ effectiveness.
- NLQ cannot make inferences. It translates what you say literally. "Find servers at risk" requires the user to define what "at risk" means — NLQ can't derive risk from multiple fields automatically.
- Complex multi-hop relationship queries ("Find all applications that depend on CIs owned by teams with an active change freeze") may exceed NLQ's translation capability and require manual query building or custom reports.
Exam Pattern — NLQ Effectiveness Depends on Data Quality
NLQ is a query interface, not a data quality tool. If the CMDB has poor completeness
or inconsistent field values, NLQ returns incomplete or incorrect results. Improving
NLQ result accuracy requires improving the underlying CMDB data quality (higher
Completeness and Compliance Health scores) — not changing NLQ configuration.
Section 3
CI 360 View — The Complete Single-CI Dashboard
When you click on any CI in CMDB Workspace or NLQ results, you are taken to the CI 360 View — a comprehensive single-screen view of everything ServiceNow knows about that CI.
What CI 360 Displays
- CI Details tab: All standard CI attributes — name, class, IP address, operational_status, support_group, owned_by, location, and all class-specific fields.
- Source Attribution tab: Which discovery source populated each field. This is the critical tab for diagnosing multi-source CMDB conflicts.
- Relationships tab: Visual map of all CIs related to this CI, with relationship type labels. Navigable — click any related CI to open its 360 view.
- CMDB Health tab: This CI's specific Health scores across all five dimensions. Shows which specific Health Rules are failing for this CI.
- ITSM Records tab: All open incidents, problems, and changes linked to this CI. Allows technicians to see operational context alongside configuration data.
- Timeline tab: History of changes to the CI record — field-level change history showing what changed, when, and by what source.
Key Concept — CI 360 Is the Primary Diagnostic Starting Point
When troubleshooting any CMDB data quality issue for a specific CI, always start
with the CI 360 view. It consolidates in one screen: what data is there,
which source put it there (Source Attribution), what's wrong with it (Health tab),
and what operational impact it has (ITSM Records tab). This eliminates the need
to navigate 4-5 different tables to gather this information.
Section 4
Source Attribution — Who Populated Which Field?
Source Attribution is one of the most important features in CMDB Workspace and directly tests your knowledge of IRE (Identity and Reconciliation Engine) in practice. The Source Attribution tab on a CI 360 view shows a field-by-field breakdown of which discovery source last successfully wrote each field value.
Why Source Attribution Matters
In a multi-source CMDB environment (Discovery + SGC + SCCM + Manual), different sources may have different "authority" over different fields (as defined by Reconciliation Rules). When a field has an unexpected value, Source Attribution tells you which source wrote that value — which is the first step in diagnosing the problem.
Analogy — Source Attribution as a Document Revision History
Think of a CI as a shared document that multiple people can edit. Source Attribution
is the revision history that shows who last changed each paragraph (field).
If "Paragraph 3" (the cpu_count field) says the wrong value, you check revision
history to see who last edited it — then you know whether to fix their source
data or fix the Reconciliation Rule that allowed them to overwrite the authoritative value.
Source Attribution Fields
| Field on CI | Source Attribution Shows | Use Case |
|---|---|---|
| ip_address | Source: Discovery | Last Updated: 2026-06-01 | Discovery owns IP — expected. If SGC shows here, Reconciliation Rule may be misconfigured. |
| owned_by | Source: Manual | Last Updated: 2025-11-15 | Manual owns ownership — expected. Stale date may indicate field hasn't been reviewed in 7 months. |
| instance_type | Source: Service Graph Connector | Last Updated: 2026-06-09 | SGC owns cloud instance type — correct. Populated yesterday so data is fresh. |
| cpu_count | Source: SCCM | Last Updated: 2024-03-01 | Stale source (SCCM) over 2 years old. Discovery should own this but may have been outcompeted by a misconfigured Reconciliation Rule. |
Exam Pattern — Source Attribution Connects IRE Theory to Practice
Exam questions often describe a scenario: "A CI shows cpu_count=4 but the server
physically has 16 CPUs. How do you identify the problem?" The answer starts with
Source Attribution (CI 360 Source tab) — which source wrote cpu_count? Then check
if that source has correct data, and whether the Reconciliation Rule for cpu_count
is configured correctly for field authority. This is the IRE diagnostic workflow
applied to a real scenario.
Section 5
Relationship Visualization — Navigating CI Dependencies
The Relationships tab in CI 360 displays all CI-to-CI relationships in a visual map. Relationships in ServiceNow CMDB are stored in the cmdb_rel_ci table. Each relationship has a type (e.g., "Runs on", "Hosted on", "Depends on", "Connected to") and a direction (parent CI → child CI).
How Relationship Navigation Works
- Starting from any CI, the Relationships tab shows direct connections (depth=1 by default).
- You can expand to show 2nd-degree connections (CIs connected to connected CIs).
- Clicking any CI in the relationship map opens its CI 360 view, allowing you to navigate the dependency chain without losing context.
- The "Impact" view shows what would be affected if this CI failed — tracing upward through the "Depends on" and "Hosted on" chains to Application Services and Business Applications (the CSDM impact propagation chain you learned in Part 5).
Tip — Use Relationship Navigation for Change Impact Assessment
Before raising a change request for a CI, use the Relationships tab to understand
the downstream impact. If you're planning maintenance on a database server,
the relationship map shows which application servers depend on it, which Application
Services those servers support, and which Business Applications are therefore at risk.
This is the CMDB delivering value to Change Management.
Section 6
CMDB Workspace vs Classic Table Navigation
| Aspect | Classic Table Navigation | CMDB Workspace + NLQ |
|---|---|---|
| Finding a CI | Must know which table the CI class uses; navigate to that table; apply filter conditions using field names | Type hostname or IP in universal search; results from all relevant CI classes |
| Viewing CI details | Open CI record form — flat field list; relationships in separate related lists; health not shown | CI 360 view — tabbed interface: details, relationships, health, source, ITSM records all on one screen |
| Asking a question | Must translate question into filter conditions manually; requires knowing field names and values | Type natural language question; NLQ translates to query automatically; visible generated query for review |
| Navigating relationships | Scroll down to "Relationships" related list; each row is text; click to open each related CI separately | Visual relationship map in CI 360 Relationships tab; navigable; impact view available |
| Data quality context | Not visible inline; must navigate to CMDB Health separately | Health scores visible in CI 360 Health tab; source attribution visible in Source tab |
| Target audience | CMDB administrators, technical staff with table knowledge | All IT roles — operations, help desk, app owners, CMDB team |
Section 7
Who Uses CMDB Workspace (Persona Map)
CMDB Workspace serves multiple IT personas, each using it differently:
- Help Desk / Service Desk: Looks up a CI by name or IP when logging an incident. Views the CI's support_group and owned_by to route correctly. Checks the ITSM Records tab to see if there's already an open incident for this CI.
- Change Manager: Uses relationship navigation to assess change impact before approving. Looks up "who owns this CI?" and "what does it support?"
- Application Owner: Uses NLQ to find all CIs associated with their application. Checks that all CIs show correct ownership fields.
- CMDB Data Steward: Uses Source Attribution to investigate data quality issues — "which source wrote this wrong value?" Uses Health tab to see per-CI Health Rule failures.
- Security Team: Uses NLQ to find CIs with specific attributes — "show me all Windows Server 2008 CIs still in production" for vulnerability assessment.
Key Concept — CMDB Workspace Serves the INSIGHT Domain
The INSIGHT exam domain (20% of exam) is about making CMDB data useful for
decision-making. CMDB Workspace, NLQ, and CI 360 are the primary tools that
serve this domain — they transform raw CMDB data into accessible, actionable
information for all IT stakeholders, not just the technical CMDB team.
Exam Quick Reference
CMDB Workspace & NLQ — Key Facts
- CMDB Workspace = unified modern interface for CMDB exploration. Navigate: Configuration → CMDB Workspace.
- NLQ (Natural Language Query) = plain-English question → structured CMDB query. Shows generated query for review.
- NLQ result quality depends on data quality. Inconsistent field values = incomplete NLQ results. Fix: improve Completeness and Compliance Health scores.
- CI 360 View = comprehensive single-CI dashboard with tabs: Details, Source Attribution, Relationships, Health, ITSM Records, Timeline.
- Source Attribution tab = field-by-field breakdown of which source last populated each value. Primary diagnostic tool for multi-source conflicts.
- Relationship visualization = visual CI dependency map from CI 360 Relationships tab. Impact view shows CSDM propagation chain upward.
- CMDB Workspace serves the INSIGHT exam domain (20% of exam) — making CMDB data accessible and actionable for all IT roles.
- NLQ cannot make inferences. Complex multi-hop relationship queries may require manual filter building or custom reports.
Term Grid
CMDB Workspace
ServiceNow's unified modern interface for CMDB exploration. Provides universal CI search, CI 360 view, NLQ, relationship visualization, and integrated CMDB Health context.
Natural Language Query (NLQ)
CMDB Workspace feature that translates plain-English questions into structured CMDB queries. Result quality depends on underlying CMDB data quality (completeness and consistency).
CI 360 View
Comprehensive single-CI dashboard in CMDB Workspace. Displays CI details, source attribution, relationships, CMDB Health scores, linked ITSM records, and change timeline in one screen.
Source Attribution
Feature in CI 360 View that shows which discovery source last populated each field on a CI, and when. Primary diagnostic tool for identifying the source of incorrect CI field values in multi-source CMDB environments.
INSIGHT Domain
CIS-DF exam domain (20% weight) covering how CMDB data is made accessible and useful for decision-making. Primary tools: CMDB Workspace, NLQ, CI 360 View, dashboards, and reporting.
Relationship Visualization
Visual CI dependency map in CI 360 Relationships tab. Shows connected CIs, relationship types, and supports impact analysis by navigating the CSDM impact propagation chain upward from CI to Business Application.
Exam Checkpoint
Practice Questions
Click any question to reveal the answer and explanation.
1. An application owner is using NLQ to find all CIs associated with her application "HRMS" but is getting fewer results than expected. She knows the CMDB has more CIs for HRMS. What is the most likely cause and recommended fix?
💡 NLQ quality depends on what? Think about the relationship between NLQ and data quality.
Answer: B — NLQ translates questions literally. If CIs use inconsistent values (HRMS vs. "HR Management System" vs. "HRMS Portal") for the field being searched, NLQ searching for "HRMS" only finds CIs that use that exact value or very close synonyms. The fix is data quality remediation: standardize how the application name is recorded across CIs. This is a Compliance dimension issue (inconsistent values) that directly degrades NLQ accuracy. There is no inherent role requirement to use NLQ (A) or a result count limit (C).
2. A CMDB administrator discovers that a production server CI shows cpu_count=4, but the physical server has 16 CPUs. Discovery should be authoritative for cpu_count per the Reconciliation Rules. Where should he look first to identify what populated the wrong value?
💡 The question asks where to look FIRST to identify what populated the wrong value — which specific view shows field-level source information?
Answer: B — Source Attribution tab in CI 360 View shows exactly which source wrote each field last, and when. If cpu_count was last written by SCCM (not Discovery), that explains the wrong value — SCCM has outdated data and its Reconciliation Rule configuration may be incorrectly granting it authority over cpu_count, or Discovery wrote 16 but SCCM later overwrote it with 4. The IRE Log (A) is valuable for understanding why IRE made a decision, but Source Attribution is the faster first step. CMDB Health (C) would show the Correctness score is low, but not which source is responsible. Discovery schedule (D) is a secondary check after confirming what source is responsible.
3. During a major incident, the help desk receives alerts about a failed database server. They use CMDB Workspace to search for the CI and open its CI 360 view. Which tab should they check FIRST to understand the operational impact — which application services and business applications are at risk?
💡 Impact during an active incident = which services depend on this CI? Which CI 360 tab shows CI dependencies?
Answer: C — During an active major incident, the priority is understanding business impact. The Relationships tab with Impact view traces the CSDM propagation chain upward: Database Server → Application Servers → Application Service → Business Application → Business Owner. This tells the help desk which business services are affected and who to notify. The Health tab (A) is useful for CMDB governance but irrelevant during an incident. Source Attribution (B) is a diagnostic tool for data quality, not operational impact. ITSM Records (D) shows historical incidents but not current business impact scope.
4. Which of the following tasks is BEST suited for CMDB Workspace NLQ versus manual filter building?
💡 NLQ is best for direct questions that translate cleanly to standard filter conditions. What are NLQ's limitations?
Answer: B — "Show me all Linux servers discovered in the last 7 days" is exactly what NLQ excels at: a direct question that maps clearly to filter conditions (class=Linux Server, last_discovered within 7 days). Option A describes the same query but as explicit filter conditions — NLQ would handle this naturally, so manually writing those conditions is unnecessary when NLQ can do it. Option C is a multi-hop relationship inference ("shares a subnet" → find related CIs → trace impact") which exceeds NLQ's translation capability. Option D is a scheduled reporting task — a different feature entirely, not NLQ.
5. A security team member uses CMDB Workspace to search for all Windows Server 2008 CIs still showing operational_status=Operational. She successfully finds 47 CIs via NLQ. What does this result demonstrate about the relationship between CMDB quality and security operations?
💡 What does this scenario demonstrate about CMDB as a source of operational intelligence for non-infrastructure teams?
Answer: B — This scenario demonstrates the INSIGHT domain in action: accurate CMDB data (correct OS version fields, current operational_status) enables the security team to perform vulnerability assessment without running separate scans. The CMDB becomes a source of operational intelligence across IT disciplines. This is why CMDB data quality matters — it's not just about keeping records; it's about enabling informed decisions across operations, security, finance, and compliance. The result depends on Discovery accurately populating OS version fields, which connects back to the entire ingestion pipeline taught in prior topics.
Exam Checkpoint
Practice Questions
4 questions · Select an answer to see the explanation immediately.
CMDB Workspace & NLQ Quiz
1 / 4
An admin discovers that cpu_count=4 on a production server CI, but the server actually has 16 CPUs. Discovery is supposed to be authoritative for cpu_count. Where should the admin look first to identify which source populated the incorrect value?
💡 Explanation
B is correct. The Source Attribution tab in CI 360 View is the fastest diagnostic tool for "which source wrote this wrong value?" It shows a field-by-field breakdown of which data source last populated each field and when. If cpu_count was last written by SCCM (not Discovery), Source Attribution reveals this immediately — and points to either a Reconciliation Rule misconfiguration (SCCM shouldn't be authoritative for cpu_count) or a timing issue (Discovery ran first with the correct value, then SCCM overwrote it). The IRE Log (A) is useful for understanding why IRE made a decision, but Source Attribution is the targeted first step for field-level source diagnosis.