PowerExams Prepare. Practice. Pass.

CIS-PA Study Guide — Certified Implementation Specialist, Platform Analytics (Performance Analytics)

Trademark disclaimer: ServiceNow, Now Platform, Performance Analytics, Platform Analytics, Now Intelligence, and related names are trademarks of ServiceNow, Inc. This is an independent, original study aid produced for exam preparation and is not affiliated with, endorsed by, or sponsored by ServiceNow, Inc. All product facts are grounded in publicly available official ServiceNow documentation; see grounding.md for source URLs.

Weighting caveat (UNVERIFIED): The percentage weights below were normalized from an official ServiceNow exam-spec table whose category sub-weights summed to ~115% rather than 100%. The relative ordering (Indicators, Breakdowns, Data Collection, and Data Visualization each dominate at roughly one-fifth of the exam; Architecture and Administration are light) is reliable, but treat any specific percentage as approximate. Confirm against the current official CIS-PA exam blueprint before relying on exact numbers.

This guide is ordered by exam weight, heaviest first. The four heavy domains — Indicators, Breakdowns, Data Collection, and Data Visualization — together account for the large majority of questions, so spend your time there.

A quick orientation on naming. ServiceNow has been consolidating its analytics capabilities under the umbrella name Platform Analytics (sometimes encountered as "Platform Analytics and Reporting," and historically as part of "Now Intelligence"). Platform Analytics unifies what used to be separate experiences — classic Performance Analytics (time-series scores, indicators, scorecards), Reporting (point-in-time reports), and dashboards — into a single workspace experience commonly called the Analytics Center. The underlying Performance Analytics engine, tables, and concepts (indicators, indicator sources, breakdowns, scores, jobs) are unchanged; the exam still tests them. Where this guide says "Performance Analytics" it refers to that engine; "Platform Analytics" refers to the modern unified experience that surfaces it.

Domain 2 — Configure Indicators and Indicator Sources (~22%, UNVERIFIED)

Indicators are the heart of Performance Analytics. An indicator (formerly called a KPI or metric) is a measurement you track over time. Each collected value is a score, and scores accumulate into a time series that you analyze for trends. This is the single most important distinction in PA versus Reporting: PA stores a history of scores at regular intervals, whereas a report shows the current state of the data.

Indicator types

There are three kinds of indicators, and knowing how each gets its scores is heavily tested.

  • Automated indicator — Collects scores automatically from a table on a regular frequency, driven by an indicator source and a data collection job. This is the default and most common type. You point it at an indicator source, choose an aggregation (count, sum, average, min, max), and the system saves a score each collection period (typically daily). Use automated indicators whenever the data lives in a Now Platform table.
  • Manual indicator — Has no indicator source. Scores are entered by hand (or imported), which suits data that does not exist in a table on the platform — for example, results from an external survey, a budget figure from a spreadsheet, or a target set by management. You can enter past scores to build history.
  • Formula indicator — Derives its scores by combining other indicators (and constants) with mathematical operators. A classic example is a percentage such as (reopened incidents ÷ resolved incidents) × 100. Formula indicators do not have their own indicator source; they reference the scores of existing indicators. Because of this they depend on those base indicators already having collected scores.

A useful exam mnemonic: automated = from a table via a source; manual = typed/imported, no source; formula = math on other indicators, no source.

Indicator sources

An indicator source defines where and which records an automated indicator measures. It specifies:

  • The facts table — the table the scores are collected from (e.g., incident).
  • A conditions filter — an encoded query that restricts which records are included (e.g., active incidents only).
  • Optionally a conditions string / additional scoping so multiple indicators can reuse one source.

One indicator source can feed many indicators; reusing sources is a best practice because it reduces redundant data collection. The collection of records that match the source at collection time is captured as a snapshot (see Data Collection). Indicator sources are the bridge between raw table data and the indicators built on top of them.

Indicator records and behavior

Key fields on an indicator include its aggregate (the function applied to the facts), unit, direction of improvement (whether higher or lower is better — this drives how trends and targets are colored), frequency (how often scores are collected), and the related indicator source. Indicators can be organized with indicator groups for management and navigation. Indicators are the objects that targets, thresholds, breakdowns, and widgets all attach to.

Domain 3 — Configure Breakdowns and Breakdown Sources (~22%, UNVERIFIED)

A breakdown lets you slice an indicator's scores along a dimension so you can see the same measurement split by category. For instance, the indicator "Open Incidents" broken down by Priority gives you open incidents per priority level, each tracked over time. Breakdowns are what make a single indicator answer many questions.

Breakdown sources and elements

  • A breakdown source defines the set of possible values (the breakdown elements) along which scores are split, and how records map to those elements. The source typically references a field (such as priority or assignment_group) or a related table.
  • Breakdown elements are the individual values within a breakdown — Critical, High, Moderate, etc. for a Priority breakdown. Scores are collected per element.
  • A manual breakdown lists its elements explicitly rather than deriving them from a field, useful when the grouping does not map to a single existing field.

Applying breakdowns to indicators

You associate a breakdown with one or more indicators (the breakdown matrix controls which indicator/breakdown combinations collect data). When data is collected, the system stores a score per breakdown element per period, multiplying the data volume — so apply only the breakdowns you need, since each breakdown element collected adds to the collection and storage load.

Breakdown relations and grouping

  • A breakdown relation connects two breakdowns so you can view scores broken down by two dimensions at once (e.g., Priority and Assignment Group). This enables pivot-style scorecards.
  • At analysis time you can group by breakdown (split the visualization into series/segments) and filter by breakdown (restrict to a single element). Distinguishing grouping from filtering is a common exam point: grouping shows all elements side by side; filtering narrows to one.

Best practice: keep the number of breakdown elements reasonable and avoid breaking down by high-cardinality fields, because the score count is multiplicative across breakdowns applied to the same indicator.

Domain 4 — Data Collection (~22%, UNVERIFIED)

Data collection is the engine that turns indicator and breakdown definitions into stored scores and snapshots. Understanding the job, what it produces, and how to operate it is essential.

Data collection jobs

A data collection job runs on a schedule and collects scores for the indicators (and their associated breakdowns) that it is configured to process. The default behavior collects scores once per period (commonly daily). Jobs can be scheduled and can also be run on demand for testing or backfilling. Each run produces:

  • Scores — one value per indicator per period, and one per breakdown element where breakdowns apply. Scores are stored in the PA score tables and form the time series.
  • Snapshots — a snapshot is the list of record sys_ids that were counted/aggregated to produce a score at collection time. Snapshots are what let you click a score on a scorecard and drill through to the exact underlying records as they existed then. Snapshots are made for indicators (subject to the "collect records for this indicator" setting).

Historic data collection

You can collect historic data to backfill scores for past periods using the data currently in the tables (an approximation, since it uses current values). This is how a new indicator gets a usable trend line immediately instead of waiting weeks for history to accumulate. Be aware historic collection is an estimate and can be resource-intensive.

Operating and troubleshooting collection

  • Job logs record what each run collected and surface errors; reviewing the data collection job log is the first step in troubleshooting missing scores.
  • Common causes of missing or wrong scores: the indicator source condition excludes the records, the breakdown matrix entry is missing, the job did not run, or the frequency is misconfigured.
  • Data cleanup / retention jobs remove old scores and snapshots per retention settings to control storage.
  • Performance considerations: limit unnecessary breakdowns, reuse indicator sources, and stagger jobs.

A frequently tested chain of cause and effect: indicator source defines records → data collection job runs on a frequency → produces scores (time series) and snapshots → scores feed widgets/scorecards → snapshots enable drill-through.

Domain 5 — Data Visualization (~21%, UNVERIFIED)

Visualization is how collected scores become insight. In the modern experience this is the Analytics Center and Platform Analytics workspace; the building blocks below apply in both classic dashboards and the unified workspace.

Widgets and visualizations

A widget is a configured visualization of one or more indicators. Widget/visualization types you should recognize:

  • Time series chart — the score history line; the signature PA visualization.
  • Score / single-score and real-time score widgets — show the latest collected value, or a live (on-the-fly) value.
  • Scorecard — a detailed analytical view of a single indicator with its trend, targets, thresholds, comparisons, and breakdowns; you can pivot a scorecard by a breakdown.
  • List / pivot widgets — tabular and cross-tabulated views, including breakdown pivots.
  • Dial, column, pie, and comparison visualizations for at-a-glance status.

Scorecards

The scorecard is the deep-dive analytical tool for one indicator. It shows the time series, applied targets and thresholds, breakdowns (with the ability to drill into elements), trendlines, and statistics. From a scorecard you can drill through a score to its snapshot records. Scorecards are where analysts spend most of their investigation time.

Targets, thresholds, and trendlines

  • A target is a goal value for an indicator (e.g., resolve 95% within SLA). Targets appear as a reference line and color the indicator according to whether you are meeting the goal, factoring in the indicator's direction of improvement.
  • A threshold defines a condition (a comparison against a value) that, when crossed, signals a status or can trigger a notification/action. Thresholds drive conditional coloring and alerting.
  • A trendline is a calculated line (e.g., moving average or linear trend) overlaid on the time series to reveal direction beyond period-to-period noise.

Dashboards and the Analytics Center

Dashboards assemble multiple widgets onto tabs for an audience. In Platform Analytics, dashboards, reports, and PA content come together in the Analytics Center workspace, giving a single place to find and view analytics. KPI Signals proactively surface notable changes/anomalies in your indicators, and KPI Details provides the in-depth, scorecard-style analysis view for a KPI. Responsive dashboards and the workspace experience are the current-release direction; classic dashboards still exist for older content.

Domain 1 — Architecture and Deployment (~9%, UNVERIFIED)

This domain covers how PA fits the platform and how you stand it up.

  • Platform Analytics unification: PA, Reporting, and dashboards are converging into one experience (Analytics Center / Platform Analytics workspace). Know that the engine (indicators, sources, jobs, scores, snapshots) is shared, while the front door is increasingly the unified workspace.
  • Solutions and content packs: Rather than building everything by hand, you deploy prebuilt content packs / Platform Analytics solutions (for ITSM, HR, CSM, ITBM/Agile, etc.). These ship ready-made indicators, sources, breakdowns, dashboards, and jobs aligned to a product area — the recommended starting point for most implementations.
  • Implementation flow: identify the questions/KPIs the business needs → choose or build indicator sources → define indicators (automated/manual/formula) → add breakdowns → schedule data collection (and optionally collect historic data) → build widgets, scorecards, and dashboards → set targets/thresholds → grant roles.
  • KPI design tooling (e.g., KPI-design wizards/composer experiences) helps translate a business question into the indicator/breakdown structure.

Domain 6 — Administration and Solutions (~4%, UNVERIFIED)

Light but real on the exam.

  • Roles: Performance Analytics ships dedicated roles. The administrator role (commonly pa_admin) can configure indicators, sources, breakdowns, jobs, and dashboards; a power-user/analyst role can create personal/shared analytics; a viewer can consume dashboards. Always grant the least privilege that meets the need. Platform Analytics workspace introduces its own role set layered on top of the classic PA roles.
  • Admin console: the Performance Analytics Admin Console is the central place to manage indicators, sources, breakdowns, jobs, and properties, and to monitor collection health.
  • Properties: PA system properties control collection behavior, retention, and feature toggles.
  • Solutions/content packs (administration side): installing, activating, and maintaining content packs; understanding that solutions bundle the full set of PA artifacts for a domain.
  • Maintenance: monitor job logs, manage score/snapshot retention, and govern who can create content to keep the instance performant.

Fast-recall cheat list

  • Indicator = a measurement tracked over time; each value is a score; scores form a time series. PA stores history; Reporting shows the current snapshot of data.
  • Automated indicator = scores from a table via an indicator source + data collection job.
  • Manual indicator = scores typed or imported, no source (use for off-platform data).
  • Formula indicator = math on other indicators, no source; depends on base indicators' scores.
  • Indicator source = facts table + conditions defining which records an automated indicator measures; reuse sources.
  • Breakdown = slice an indicator by a dimension; breakdown source defines the elements (values).
  • Manual breakdown = elements listed explicitly, not from a field.
  • Breakdown relation = two breakdowns combined → pivot scorecards.
  • Group by breakdown = show all elements; filter by breakdown = show one element.
  • Breakdowns are multiplicative on stored scores — apply sparingly; avoid high-cardinality fields.
  • Data collection job = scheduled (often daily); produces scores + snapshots; can run on demand.
  • Snapshot = the list of record sys_ids behind a score → enables drill-through to records.
  • Collect historic data = backfill past scores from current data (an estimate) to seed the trend.
  • Troubleshoot missing scores via the data collection job log; check source condition, breakdown matrix, schedule.
  • Scorecard = deep analysis of one indicator (trend, targets, thresholds, breakdowns, drill-through).
  • Target = goal line; threshold = condition that signals status/alert; trendline = calculated trend overlay. Direction of improvement colors targets/thresholds.
  • Widgets: time series, score/real-time score, scorecard, list/pivot, dial/column/pie.
  • Dashboard = collection of widgets on tabs; Analytics Center = the unified Platform Analytics workspace bringing PA + Reporting + dashboards together.
  • KPI Signals = proactive anomaly/change alerts; KPI Details = in-depth KPI analysis view.
  • Content packs / Platform Analytics solutions = prebuilt PA artifacts per product area — preferred starting point.
  • pa_admin = PA administrator; Admin Console = central PA management; manage retention via cleanup jobs.
  • Platform Analytics = modern unified experience over the unchanged PA engine.