› CIS-DF Hub › Part 7 › Report Types & Report Builder
⬡ Part 7 · Topic 1

Report Types & Report Builder

ServiceNow's Report Builder lets you create visualizations directly from table data. Knowing which report type to use for which scenario, and how grouping and aggregation work, is consistently tested on the exam.

📋 5 sections ⏱ ~18 min read 🎯 ~7% exam weight 🏷 Reporting · Analytics
Section 1

Report Builder Overview

Every ServiceNow report is built in the Report Builder — a wizard-style interface where you choose a data source (table), apply filters, select fields, choose a visualization type, and configure grouping/aggregation. Reports are stored in the sys_report table.

Navigate to Report Builder: All → Reports → Create New (or from any list view: the "Reports" icon). You can also create a report directly from a list by right-clicking a column header and selecting "Show Visual Task Board."

Report Builder Sections

  • Data — choose the table and apply a filter condition (encoded query). This is the report's scope.
  • Type — select the visualization type (bar, pie, list, etc.)
  • Configure — set grouping fields, aggregation function (COUNT, SUM, AVG), and axis labels
  • Style — colors, legend position, chart title
  • Sharing — who can view the report; add to dashboards
Section 2

Report Types

Choosing the right report type for the data you're presenting is a tested skill. Each type is optimized for different data shapes and audience needs.

List
Tabular display of records. Best when you need to show individual records with multiple field columns. Supports sorting and grouping.
Bar / Horizontal Bar
Count or sum of records by category. Best for comparing quantities across discrete categories (e.g., open incidents by team).
Pie / Donut
Part-to-whole relationship. Best when showing the proportion each category contributes to a total (e.g., incident priority breakdown).
Line
Trends over time. Best for showing how a metric changes across a date range. Requires a date/time field on the X axis.
Trend
Similar to Line but designed for Performance Analytics data. Shows metric values tracked over time with context bands.
Pivot Table
Cross-tabulation of two grouping dimensions. Best for comparing two categorical variables simultaneously (e.g., incidents by priority AND by team).
Heatmap
Grid with color intensity representing value. Best for showing density or patterns across two categorical axes.
Scorecard
Single KPI metric with target comparison. Best for executive dashboards where one number tells the story.
⚠
Exam Trap — Line Chart Requires a Date Field Line charts show trends over time, so the X axis must be a Date or DateTime field. If you group by a non-date field (like category), ServiceNow will suggest a Bar chart instead. Similarly, Trend reports require Performance Analytics data (scorecard indicators) — you can't use a standard Trend report on ad-hoc table data.
Section 3

Grouping and Aggregation

Most report types aggregate data by grouping records and counting or summing them. Understanding how grouping works prevents common mistakes:

  • Group by — the field whose distinct values become categories (X axis or pie slices). Each unique value in this field gets its own bar/slice.
  • Aggregation — what to calculate for each group: COUNT (number of records), SUM (total of a numeric field), AVG (average of a numeric field), MIN, MAX.
  • Stack by — in bar charts, adds a secondary grouping field that splits each bar into colored segments.
📘
Core Concept — Group By Reference Fields When you group by a Reference field (like "Assignment Group"), the report uses the display value of the reference (the group name), not the sys_id. This means the report shows human-readable category names automatically. However, if a referenced record is deleted, the group still appears with a blank or "[unknown]" label until the report data is refreshed.
Section 4

Report Visibility and Sharing

Reports have a visibility setting that controls who can see them:

VisibilityWho Can See
MeOnly the report creator
GroupSpecific user groups selected by the creator
GlobalAll users with access to the Reports module

Additionally, reports can be added to Dashboards as widgets. A report must be set to at least "Group" or "Global" visibility to be added to a shared dashboard — a report visible only to "Me" can't be shared on a group dashboard.

⚠
Exam Trap — Report Visibility vs. ACL Report visibility controls whether users can find and view the report definition. But when a user runs a report, the underlying data is still filtered by that user's ACLs. A user without access to certain CI records won't see those records in the report results, even if the report itself is "Global" visibility. Report visibility ≠ data access.
Section 5

Reports on CMDB Data

Reports are a primary tool for monitoring CMDB data quality and CI inventory. Common CMDB reporting scenarios:

  • CI inventory by class — List or Bar chart on cmdb_ci grouped by sys_class_name
  • Stale CI detection — List of CIs where last_discovered is older than 90 days
  • CI ownership gaps — List of CIs where managed_by is empty
  • Operational status distribution — Pie chart on cmdb_ci grouped by operational_status

When reporting on CMDB data, be aware that querying cmdb_ci without a class filter returns all CI types from all child tables. This can produce very large result sets. Always add a sys_class_name filter or use a specific child table as the report's data source.

Exam Quick Reference

Common Exam Traps — Report Types & Builder

  • Report Builder wizard sections: Data → Type → Configure → Style → Sharing
  • Line chart requires a Date/DateTime field on X axis
  • Trend report requires Performance Analytics indicator data (not ad-hoc table data)
  • Pivot Table = two grouping dimensions in a cross-tab grid
  • Report visibility (Me/Group/Global) controls who sees the report — not the data within it
  • Report data is still filtered by the viewing user's ACLs regardless of report visibility
  • Group by Reference field uses the display value (name), not the sys_id
  • Query cmdb_ci without class filter returns ALL CI types — always add class filter
Exam Checkpoint

Practice Questions

4 questions · Select an answer to see the explanation immediately.

Report Types & Report Builder Quiz 1 / 4

A manager shares a report showing all open Incidents with the entire IT department. A junior analyst views the report and sees only 15 incidents, while a senior engineer sees 200 incidents. Why?

💡 Explanation

B is correct. Report visibility (Me/Group/Global) controls who can see and run the report — not what data appears in it. When two users run the same report, they each see different results based on their individual ACLs. If the junior analyst can only read incidents assigned to their team, they'll see 15. If the senior engineer has broader ACL access, they'll see 200. The report definition is identical; the data returned is filtered by each viewer's permissions. This is a fundamental ServiceNow security behavior that applies to all reports and dashboards.

An administrator wants to build a line chart showing incident volume over the past 6 months, with month on the X-axis. Which field must be available on the Incident table for this chart type?

💡 Explanation

B is correct. Line charts in the Report Builder require a Date or DateTime field on the X-axis to plot data over time. Without a date field, you cannot create a line chart — it's a hard requirement. The field must be of type Date or DateTime (like sys_created_on, opened_at, or closed_at). Option C would be needed for a Trend chart type (PA-based), not a standard line chart. Choice fields (D) could group data but don't provide the time-series axis needed for a line chart. Reference fields (A) don't provide date-based time axis functionality.

A report is built on the cmdb_ci table to count all CIs. The result shows 250,000 records. When the analyst runs the same filter but on cmdb_ci_server, it returns only 8,000. Why is the cmdb_ci query problematic?

💡 Explanation

B is correct. In ServiceNow's table inheritance model, all CI classes (cmdb_ci_server, cmdb_ci_netgear_switch, cmdb_ci_linux_server, etc.) extend the base cmdb_ci table. Querying cmdb_ci without a class filter (sys_class_name=cmdb_ci_server) returns every CI of every type — all 250,000. This is correct behavior but often produces unintended results when the goal is a specific CI class analysis. Best practice: always add a sys_class_name filter in CMDB reports. The 250,000 number (D) is expected when querying the base table without a class constraint — parent tables always have more records than individual child classes.

A report groups Incidents by "Assigned to" (a reference field to sys_user). The report shows "John Smith" as a group label. What value is actually stored in the database for the assigned_to field?

💡 Explanation

B is correct. Reference fields in ServiceNow store the sys_id (GUID) of the referenced record in the database, not the display name. The Report Builder automatically resolves the sys_id to the display value (John Smith's name) for human-readable group labels — but the underlying stored value is always a sys_id. This has practical implications: when filtering a report or condition on a reference field, you filter by sys_id (or use the display value lookup), not by a readable name. Scripts working with reference fields need to use .getDisplayValue() to get the name, or .getValue() to get the sys_id.

Score: 0 / 4
Database Views in Reporting →