pa_indicators Table — ServiceNow Reference

Table Reference/pa_indicators

The `pa_indicators` table stores Performance Analytics KPI definitions, including data collection queries, aggregation types, and collection schedules. Owned by the Performance Analytics module, it's the foundation for all PA dashboards and requires careful handling of the `aggregate_type` field when scripting collection logic.

What This Table Is

The pa_indicators table stores KPI definitions that power Performance Analytics dashboards and reports. Each record defines what data to collect (through the collection_query field), how to aggregate it (aggregate_type), and when to collect it (collection_schedule).

Owned by the Performance Analytics module, this table is the configuration backbone for automated KPI collection. The PA framework reads these definitions and executes the collection queries on schedule, storing results in pa_snapshots and pa_cube_fact tables. The indicators drive the entire PA collection pipeline from data extraction to dashboard visualization.

This table doesn't extend task or any other core table—it's a standalone configuration table. No tables extend pa_indicators, but it has critical relationships with pa_cubes (parent container), pa_m2m_cube_indicator (cube assignments), and pa_collection_log (execution history).

Large enterprises typically have 200-500 active indicators across all cubes. Each indicator can generate thousands of snapshots daily depending on breakdown configuration. Query performance is generally good since most scripting reads indicator metadata rather than processing collection data—that heavy lifting happens in the PA framework's scheduled jobs.

When You'll Script Against This Table

You'll primarily script against pa_indicators in Business Rules when building PA automation, Script Includes for custom collection logic, and Scheduled Jobs for bulk indicator management. The most common pattern is querying indicator definitions to programmatically trigger collections or validate KPI configurations before deployment.

Access requires pa_admin role for writes and pa_power_user for reads. The table respects domain separation—indicators in global domain are visible to all, but scoped indicators follow standard domain ACL patterns. No record-level security exists beyond domain restrictions.

Validate collection queries before indicator activation using GlideRecord.isValidQuery()
Clone indicators across cubes by copying definition fields and updating cube references
Bulk activate/deactivate indicators based on cube status or collection performance
Generate indicator documentation by extracting name, description, and collection_query fields
Monitor collection failures by joining with pa_collection_log on indicator sys_id
Build custom collection triggers that execute specific indicators outside their normal schedule
Audit indicator changes by comparing collection_query field between versions

Table Gotchas

⚠️

The `aggregate_type` field stores encoded values that don't match the UI labels. 'SUM' displays as 'Sum' but the database value is '1', 'COUNT' is '2', 'AVG' is '3'. Always query by the numeric code, not the display value.

The collection_query field accepts complex queries but doesn't validate syntax until collection runs—test queries before saving indicators

⚠️

Changing an active indicator's `collection_query` doesn't automatically recollect historical data. Existing snapshots remain unchanged, potentially creating inconsistent time series.

The active field behaves as expected, but inactive indicators still appear in cube configuration UI—filter by both active=true and cube assignment status
Performance trap: avoid CONTAINS queries on collection_query field—it's not indexed and queries are expensive with large text values

⚠️

The `unit` field is purely cosmetic for dashboard display. Changing it doesn't convert existing snapshot values—you'll have mixed units in historical data.

The order field controls dashboard display sequence but doesn't affect collection execution order—that's controlled by collection_schedule

Free Newsletter

Enjoying this? Get one deep-dive per week.

Join 1,000+ ServiceNow pros — scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.

This table doesn't extend a parent, but has tight integration with pa_cubes which provide the organizational container for indicators. The pa_m2m_cube_indicator table manages many-to-many relationships, allowing indicators to belong to multiple cubes. You'll frequently join these three tables when building comprehensive PA reports or management interfaces.

The pa_snapshots and pa_cube_fact tables store the actual collected data generated by these indicator definitions. When troubleshooting collection issues or building custom analytics, you'll query pa_indicators for the configuration and pa_collection_log for execution history. The cmn_schedule table defines when collections run, referenced by the indicator's collection_schedule field.

For breakdown and dimension analysis, developers commonly join with pa_breakdowns and pa_dimensions tables. These define how collected data gets segmented and categorized in dashboards. When building automated PA solutions, you'll typically start with pa_indicators to understand what's being measured, then follow relationships to cubes, schedules, and fact tables.

Chrome Extension

Sourdough: ServiceNow Monitoring and Analytics

A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.

Instance HealthGraphs & ChartsAPI HealthDeveloper ToolsQuick SearchInstance Switcher

Add to Chrome

Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.

Overview

Tasks

CMDB

API

Metrics

Monitor

Internals

Instance:sourdoughdev·Version:Yokohama

Instance StateONLINE

System StatusFully Operational

Session Timeout90 minutes

Logged-In Sessions2 (20 active)

Build Nameyokohama-12-18-2024_p1

IP Address10.159.128.43

Instance HealthHealth Score: 90%

🔥 5dSourdough (Chrome Plugin)Dark Mode

Key Fields

Column	Type	Label	Notes
active	boolean	Active	Controls whether the PA framework collects data for this indicator. Inactive indicators remain in cube configurations but don't execute collection queries.
aggregate_type	choice	Aggregate type	Defines how collected values are aggregated (SUM=1, COUNT=2, AVG=3, etc.). Database stores numeric codes, not display labels.
collection_query	string	Collection query	The GlideRecord query that extracts data from source tables. Supports complex conditions but syntax isn't validated until collection execution.
collection_schedule	reference	Collection schedule	References cmn_schedule table to determine when this indicator's data collection runs. Shared schedules affect multiple indicators simultaneously.
cube	reference	Cube	Primary cube assignment referencing pa_cubes. Indicators can belong to multiple cubes via pa_m2m_cube_indicator relationships.
description	string	Description	Business description of what this KPI measures. Displayed in dashboards and used for documentation generation scripts.
field	string	Field	The field name from the collection query's source table that provides the numeric value to aggregate. Must be a numeric field type.
name	string	Name	Unique identifier for the indicator within its cube context. Used in API calls and automation scripts to reference specific KPIs.
order	integer	Order	Display sequence in dashboards and reports. Doesn't affect collection execution order, which depends on collection_schedule timing.
table	string	Table	Source table name for the collection query. Must be a valid ServiceNow table that exists when the collection job executes.
target	decimal	Target	Optional target value for KPI goals. Used by dashboard widgets to show performance against targets but doesn't affect collection logic.
threshold_high	decimal	High threshold	Upper threshold for dashboard color coding and alerting. Purely visual—doesn't trigger automatic actions when exceeded.
threshold_low	decimal	Low threshold	Lower threshold for dashboard indicators. Combined with high threshold to create red/yellow/green status visualization.
type	choice	Type	Indicator category (Formula, Automated, Manual). Automated indicators use collection_query; Manual indicators accept external data input.
unit	string	Unit	Display unit for dashboard labels (e.g., 'minutes', 'count', '%'). Cosmetic only—changing doesn't convert existing snapshot values.

Common Queries

Get all active indicators with their cube information

var gr = new GlideRecord('pa_indicators');
gr.addQuery('active', true);
gr.orderBy('name');
gr.query();

while (gr.next()) {
    var cubeName = gr.cube.getDisplayValue();
    var schedule = gr.collection_schedule.getDisplayValue();
    gs.info('Indicator: ' + gr.name + ' (Cube: ' + cubeName + ', Schedule: ' + schedule + ')');
}

Find indicators for a specific cube that use SUM aggregation

var gr = new GlideRecord('pa_indicators');
gr.addQuery('cube.name', 'Incident Management'); // Replace with actual cube name
gr.addQuery('aggregate_type', '1'); // SUM = 1, not 'SUM'
gr.addQuery('active', true);
gr.query();

while (gr.next()) {
    gs.info('SUM indicator: ' + gr.name + ' -> Field: ' + gr.field + ' from ' + gr.table);
}

Get indicators with failed collections in the last 24 hours

var gr = new GlideRecord('pa_indicators');
gr.addQuery('active', true);
gr.query();

while (gr.next()) {
    var logGR = new GlideRecord('pa_collection_log');
    logGR.addQuery('indicator', gr.sys_id);
    logGR.addQuery('sys_created_on', '>=', gs.daysAgoEnd(1));
    logGR.addQuery('status', 'failed');
    logGR.query();
    
    if (logGR.hasNext()) {
        gs.warn('Failed collections for indicator: ' + gr.name);
    }
}

Count indicators by aggregate type across all cubes

var ga = new GlideAggregate('pa_indicators');
ga.addQuery('active', true);
ga.addAggregate('COUNT');
ga.groupBy('aggregate_type');
ga.query();

while (ga.next()) {
    var aggType = ga.aggregate_type.toString();
    var count = ga.getAggregate('COUNT');
    var typeName = aggType == '1' ? 'SUM' : aggType == '2' ? 'COUNT' : 'OTHER';
    gs.info(typeName + ' indicators: ' + count);
}

Wrong vs right way to find indicators by collection query content

// WRONG - expensive CONTAINS query on large text field
// var gr = new GlideRecord('pa_indicators');
// gr.addQuery('collection_query', 'CONTAINS', 'incident');

// RIGHT - filter by table field first, then check query if needed
var gr = new GlideRecord('pa_indicators');
gr.addQuery('table', 'incident');
gr.addQuery('active', true);
gr.query();

while (gr.next()) {
    // Now check collection_query content if still needed
    if (gr.collection_query.toString().indexOf('state=2') > -1) {
        gs.info('Found incident indicator checking for resolved state: ' + gr.name);
    }
}

Related Tables

cmn_schedule

Test Your Knowledge

Quick 3-question quiz — see how your ServiceNow skills stack up.

Question 1 of 3Performance

A list view on a table with millions of records is slow. Best fix?

Select an answer to continue