Reporting & Dashboards

Reports Overview

ServiceNow reports allow administrators and users to visualize data stored on the platform. Reports are created against a table or data source, filtered by conditions, and rendered in a variety of chart or list formats. They are stored in the sys_report table.

• Reports are stored in: sys_report table
• Navigate to: Reports > View/Run or type sys_report.list in the filter navigator
• Create a new report: Reports > Create New
• Reports can be run on-demand, scheduled, or embedded in dashboards
• Report scope controls whether a report is global or application-specific

Report Types

ServiceNow supports a wide range of visualization types. Knowing when each type is appropriate is exam-testable.

Creating a Report — Core Steps

The standard flow for building a report in ServiceNow follows a consistent four-step pattern:

Report Scope: Global vs. Application

Report Builder Anatomy

The Report Builder is the primary interface for creating and editing reports. Each configuration field within the builder has a distinct purpose — understanding them precisely is key to answering exam scenario questions correctly.

Source: Table vs. Data Source

Key Report Builder Fields

Aggregate Functions

The Aggregate field determines how grouped records are measured. Choosing the wrong aggregate is a common source of incorrect exam answers.

Dot-Walking in Report Conditions

Dot-walking allows report conditions to traverse reference fields and filter on fields from related (parent or child) tables. This is a powerful feature that makes it possible to filter incidents by the caller's department without needing a separate join.

// Filter incidents by the caller's department (dot-walk through caller_id → sys_user → department)
caller_id.department = "IT"

// Filter incidents by the assignment group's manager (dot-walk through assignment_group → sys_user_group → manager)
assignment_group.manager = "John Smith"

// Filter CIs by their location's city (dot-walk through location → cmn_location → city)
location.city = "New York"

Dashboards

Dashboards are visual workspaces that aggregate multiple reports and data widgets on a single configurable canvas. They provide at-a-glance operational visibility without requiring users to run individual reports.

• Navigate to: Reports > Dashboards or search "Dashboard" in the filter navigator
• Dashboards are built by adding Widgets to a layout grid
• Each dashboard can have multiple Tabs to organize widgets by category or audience
• Dashboards support real-time or periodically refreshed data

Widget Types

Dashboard Sharing

Dashboards have a Sharing configuration that determines who can view and edit them. This is separate from report-level "Visible to" settings.

Tab Management

Dashboards support multiple tabs, allowing you to organize widgets logically within a single dashboard. Each tab has an independent layout and can display a different set of widgets.

• Add a new tab via the + icon on the dashboard tab bar
• Tabs can be renamed, reordered, and deleted independently
• Each tab can have its own sharing configuration (in newer ServiceNow versions)
• Tabs are useful for separating views — e.g., "Overview," "SLA Status," "Team Performance"

Interactive Filters on Dashboards

Interactive Filters allow dashboard viewers to slice all applicable widgets simultaneously without modifying the underlying reports. They act as a dynamic cross-dashboard filter.

• Added to a dashboard as a widget — appears as a dropdown or date picker at the top of the canvas
• When a user selects a value (e.g., "Priority = 1 - Critical"), all widgets that use the same source table and field update dynamically
• Interactive filters are not saved to the underlying reports — they are temporary view-time overrides
• Useful for executive dashboards where stakeholders need to filter by date range, region, or team without creating separate reports

Performance Analytics (PA)

Performance Analytics (PA) is a licensed ServiceNow application that extends standard reporting with historical data collection and time-series trending. While standard reports reflect the current state of data, PA captures point-in-time snapshots and tracks how metrics evolve over time.

Core PA Concepts

PA vs. Standard Reports — Critical Comparison

This comparison is one of the most commonly tested topics in the reporting section of the CSA exam.

Automated Data Collection Jobs

PA data collection jobs are scheduled system jobs that automatically run at configured intervals to capture indicator scores. Key facts:

• Jobs are configured under: Performance Analytics > Data Collector > Jobs
• Each job is associated with one or more indicators
• Jobs can be triggered manually or run on a schedule (daily, weekly, etc.)
• If a job has never run, there are no scores and no historical data to display
• Backfilling historical scores is possible but requires a data collection job with a historical range configured

Scheduled Reports

Scheduled Reports automatically run a report on a defined interval and distribute the output to specified recipients via email. This eliminates the need for users to manually run reports on a recurring basis.

• Scheduled reports are stored in the sys_report_schedule table
• Navigate to: Reports > Scheduled Reports or type sys_report_schedule.list
• A scheduled report is associated with one or more existing saved reports
• The schedule runs a fresh query against the live data at the configured time

Schedule Configuration

Data Sources

A Data Source is a reusable, pre-configured query definition that can serve as the basis for one or more reports. Instead of configuring the same table, joins, and filters on each report individually, a Data Source encapsulates that configuration and allows multiple reports to share it.

• Data Sources are stored in the sys_data_source table
• Navigate to: Reports > Data Sources
• A Data Source can reference a single table or use dot-walking to traverse related tables
• Complex multi-table relationships can be modeled using dot-walked fields as virtual columns

Joining Tables via Dot-Walk

ServiceNow does not have native SQL-style JOIN syntax for reports, but dot-walking through reference fields effectively achieves the same result. A Data Source based on the incident table can expose caller_id.department, caller_id.location.city, and assignment_group.manager.name as available fields — bringing in data from related tables transparently.

// Example Data Source on incident table exposing cross-table fields via dot-walk
Source Table: incident

Available dot-walked fields:
  caller_id.name              → Caller's full name (from sys_user)
  caller_id.department.name   → Caller's department name (from cmn_department via sys_user)
  assignment_group.name       → Assignment group name (from sys_user_group)
  assignment_group.manager.name → Group manager name (from sys_user via sys_user_group)
  location.city               → Location city (from cmn_location)

Encrypted Tables and Report Restrictions

ServiceNow supports field-level encryption for sensitive data. Reports on tables with encrypted fields are subject to the following restrictions:

• Encrypted fields cannot be used as Group By dimensions — the encrypted value cannot be aggregated or compared meaningfully
• Encrypted fields cannot appear in report filter conditions unless queried with the exact encrypted hash
• Users without the encryption key or appropriate role will see masked or blank values for encrypted fields in report output
• Report administrators should be aware of these constraints when designing reports against HR or financial tables that use encryption

Key Exam Facts & Traps

This section consolidates the highest-frequency exam facts for the Reporting & Dashboards topic. Review these before the exam.

Quick Reference Summary