CIS-PA Study Guide: Certified Implementation Specialist, Platform 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. The exam is now called Certified Implementation Specialist - Platform Analytics (CIS-PA); it was previously the Certified Application Specialist - Performance Analytics (CAS-PA) exam. ServiceNow groups its analytics applications (Reporting, Performance Analytics, Usage Insights, Process Mining) under the name Platform Analytics (historically "Performance Analytics and Reporting" and "Now Intelligence"). In Zurich there are two front ends:

The Platform Analytics experience (All > Platform Analytics), whose home page is the Analytics Center and whose Library lists dashboards and data visualizations. Here data visualizations replace both PA widgets and reports, and KPI Details replaces the Analytics Hub.
The Core UI, where Performance Analytics widgets sit on responsive dashboards and indicators are explored in the Analytics Hub (which itself replaced the old detailed scorecard).

The Performance Analytics back end (indicators, indicator sources, breakdowns, breakdown sources, data collection jobs, scores) is the same in both and is administered under All > Platform Analytics Administration. Where this guide says "Performance Analytics" it means that back end.

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

Indicators are the heart of Performance Analytics. An indicator (also called a KPI) 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

Know how each type gets its scores.

Automated indicator: Collects scores from an indicator source in scheduled data collection jobs. This is the most common type. You point it at an indicator source, choose an aggregate (Count, Count Distinct, Sum, Average, Minimum, Maximum, or a script), and a score is stored for each collection period. Use automated indicators whenever the data lives in an instance table.
Manual indicator: Has no indicator source. Scores are entered by hand in the scoresheet (or imported), which suits data that does not exist in an instance table, for example results from an external survey or a budget figure.
Formula indicator: Calculates its score from other indicators (and constants) with a formula, referencing each indicator in double square brackets, for example [[Reopened]] / [[Resolved]] * 100. Formula indicators have no indicator source and are not collected: their scores are calculated when a user views the indicator. By default, if any contributing indicator has no score for a period, the formula returns no score; Allow formula component to be NULL changes that. An indicator that is used in a formula indicator cannot be deleted until the formula indicators are dealt with.
External indicator: An advanced option for scores that come from an external data source.

A useful mnemonic: automated = from a source via a job; manual = typed or imported, no source; formula = math on other indicators, calculated when viewed.

Indicator sources

An indicator source is a data set of filtered records from one table or database view. It specifies:

The facts table (for example incident).
Conditions that filter the records, normally including a date-related condition such as [Opened][on][Today] for a daily indicator.
The Valid for frequency (daily, weekly, monthly and so on). Indicators based on the source use it as their Frequency, which sets the length of each score collection period.

Indicator sources must exist before you can create an automated indicator. Many indicators can share one indicator source, and that is best practice: data collection queries the database once per indicator source, so all indicators on a source get data from the same point in time. Each indicator can add its own Additional conditions on top of the source conditions.

Indicator records and behavior

Key fields on an automated indicator include its aggregate, unit, direction (Minimize, Maximize, or None: whether lower or higher is better, which drives the score color, the change arrow, and the gap to target), precision, Collect records (stores snapshots of the record sys_ids so users can drill down), and Value when nil (the value inserted as the score when no value is collected; it is not used to calculate formulas or aggregates such as an average). The docs advise avoiding the Average aggregate where possible and dividing a Sum indicator by a Count indicator in a formula instead. Indicators can be organized with indicator groups. Targets, thresholds, breakdowns, and visualizations all attach to indicators.

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

A breakdown lets you slice an indicator's scores along a dimension. For instance, the indicator "Open Incidents" broken down by Priority gives you open incidents per priority, each tracked over time.

Breakdown sources, elements and mappings

A breakdown source specifies which unique values, called breakdown elements, a breakdown contains. It is defined as a set of records from a table or database view (using a field with a unique value per record, usually Sys ID), or as a bucket group. For example, a Groups source takes its elements from Group [sys_user_group] records, and the Incident.Category source takes its elements from Choice records. Multiple breakdowns can use the same breakdown source.
A breakdown mapping is defined on the breakdown, per facts table: it names the field on the indicator source that references the breakdown source (for example the incident Assignment group field), or a script when no simple field exists. One breakdown can have mappings for several facts tables, so it can be reused across indicators on different sources.
Records whose mapped field is empty, or matches no element, are scored under the Unmatched element (the default value of Label for unmatched on the breakdown source).
A bucket group groups values into labeled buckets, for example numeric ranges or the true and false values of a boolean.
A manual breakdown has elements you define yourself and broken-down scores that users enter manually; it does not map to any fields on an indicator source and is used with manual indicators.

Configuration order for an automated breakdown: breakdown source, breakdown, breakdown mapping, assign the breakdown to the indicator, then collect.

Breakdown matrix

When at least two breakdowns are assigned to an automated indicator and Collect breakdown matrix is enabled, the instance also collects the two-breakdown combinations (for example priority within each assignment group). These second-level scores are stored in Scores Level 2 [pa_scores_l2]. Breakdown matrix exclusions stop collection of meaningless breakdown pairs, for example Country with Region, which only repeats the Country scores; scores for the individual breakdowns are still collected. The property com.snc.pa.dc.max_breakdown_elements_level2_limit caps second-level elements, and if a breakdown source exceeds com.snc.pa.dc.max_breakdown_elements_limit, the data collector skips that source entirely.

Breakdown relations, grouping and security

A breakdown relation sets up navigation between breakdown elements: between parent and child elements of one hierarchical breakdown (country to city), or between the elements of two breakdowns (an assignment group to its members). It is not the way to collect two-dimensional scores; that is the breakdown matrix.
At analysis time you can apply a breakdown to see all its elements side by side, or select one element to filter the scores to it.
Element security (ACLs on the breakdown source) limits which breakdown elements a subset of users can view, in widgets, workspaces and the Analytics Hub.

Best practice: avoid high-cardinality breakdowns and unnecessary matrix combinations, because every element (and every combination) adds scores to collect and store.

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

Data collection turns indicator and breakdown definitions into stored scores and snapshots.

Data collection jobs

A data collection job (All > Platform Analytics Administration > Data Collector > Jobs) collects scores for the automated indicators in its Indicators related list (its job indicators). Its Run field sets when it executes (daily, weekly, monthly, periodically, once, or on demand); the period length of the scores comes from the indicator Frequency, so the job schedule is set to match it. Each solution provides its own jobs, typically one historic job and one periodic job, such as [PA Incident] Historic Data Collection and [PA Incident] Daily Data Collection, and solution periodic jobs must be activated. Each run produces:

Scores: one per indicator per period, plus one per breakdown element (and matrix combination) where breakdowns apply. Scores are stored in Scores Level 1 [pa_scores_l1] and Scores Level 2 [pa_scores_l2]; the old Scores [pa_scores] table is deprecated.
Snapshots: the lists of record sys_ids collected with the scores, stored in Snapshot [pa_snapshots]. Only automated indicators with Collect records enabled have snapshots. They enable drilling down from a score to the records behind it, as they were at collection time.

Historical data collection

Run a historical data collection job once to collect scores and snapshots for existing records, for example when you set up a new indicator. Key rules:

Set its Run field to On demand; never run historical jobs on a fixed schedule.
A historical job deletes any previously collected data for the periods and indicators it covers (and nothing outside that range or those indicators), so avoid running it more than once and consider a separate job for a new indicator.
It reconstructs history from current record values, so exclude breakdowns on fields whose values change over time (such as Assignment group or State), because their historical results would be meaningless.
To add history for a newly added breakdown without overwriting indicator scores, use a one-off job limited to that breakdown with Collect indicator cleared.

Operating and troubleshooting collection

Job logs (Data Collector > Job Logs) show each run's State, Run time, warnings, and errors, and the job log details describe each step per indicator source and collection period. They are the first place to look for missing scores.
Diagnostics (Troubleshooting > Diagnostics) run predefined scripts that find configuration issues.
Common causes of missing scores: the job did not run or the indicator is not in it, the source or indicator conditions exclude the records, the breakdown is not assigned or mapped, or the breakdown source exceeds the element limit.
Retention: com.snc.pa.dc.keep_scores_for.frequency sets how many periods of scores are kept (732 for daily indicators by default), and snapshots are kept for 183 days by default (com.snc.pa.dc.keep_snapshots_for.frequency); the scheduled cleanup job deletes older data. Both can be overridden per indicator.
Value when nil fills a period with a chosen score when no value is collected.

Chain of cause and effect: indicator source defines records → data collection job runs → produces scores (time series) and, with Collect records, snapshots → scores feed visualizations, KPI Details and the Analytics Hub → snapshots enable drilldown.

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

Data visualizations and widgets

In the Platform Analytics experience, data visualizations (time series, single score, column, pie, list, indicator scorecard and others) are created in the Visualization Designer and placed on Platform Analytics dashboards. In the Core UI, the equivalent are Performance Analytics widgets (time series, score, breakdown, list and other widgets) on responsive dashboards. Visualization types to recognize:

Time series: the score history line, the signature PA visualization; it can show targets, thresholds, a trend line, a previous-period comparison, and a forecast.
Single score / latest score and real-time score: the latest collected value, or a live value calculated from the facts table.
Breakdown visualizations: column, pie, list and similar charts of the elements of one breakdown.
Speedometer and dial: a single value as a gauge. The speedometer reproduces the indicator target and its traffic light; the dial does not show the target.

KPI Details and the Analytics Hub

KPI Details (Platform Analytics experience) and its Core UI equivalent, the Analytics Hub, are the in-depth view of one indicator: its time series, targets, thresholds, breakdowns and elements, statistics, comparisons, and drilldown to snapshot records. This is where targets and thresholds are created. The old "detailed scorecard" was replaced by the Analytics Hub.

Targets, thresholds, trend lines and forecasts

A target is a goal value for an indicator, optionally for a breakdown element and from a start date. A target color scheme (by default the 3-color or 5-color traffic light, set on a global target) colors the score by its position relative to the target, taking the indicator direction into account.
A threshold defines the normal range of scores and alerts you when certain events occur, such as a score reaching an all-time high: the instance generates an email notification, and the threshold appears as a dotted line on time series charts. Thresholds are not the source of traffic-light coloring. Global thresholds need pa_threshold_admin (or pa_power_user, pa_admin); global targets need pa_target_admin.
A trend line shows the general direction of the displayed scores; a forecast projects future scores and must be configured on the indicator.

Dashboards, filters and signals

Dashboards assemble visualizations or widgets for an audience. Sharing (users, groups, and role restrictions) controls who can open a dashboard, and Performance Analytics content follows indicator and breakdown ACLs. Collected scores are not filtered by facts table ACLs; only real-time scores are.
On Platform Analytics dashboards, a filter applies to visualizations based on the same table or indicator breakdown. In the Core UI, interactive filters filter reports, but Performance Analytics widgets do not follow them; they are filtered with breakdown dashboard controls.
Personalized visuals use dynamic elements so each viewer sees only, for example, their own groups.
KPI Signals applies process behavior charts (3-sigma) to indicators and notifies responsible users of significant changes. Spotlight ranks records (not indicators) by weighted criteria, for example to triage overlooked incidents.

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

Back end and front ends: the PA back end (indicators, sources, jobs, scores, snapshots) is shared; the Platform Analytics experience and the Core UI are two front ends over it. In Zurich, Core UI and Platform Analytics experience dashboards sit side by side in the Platform Analytics library, and the Migration Center moves Core UI content into Platform Analytics.
Platform Analytics Solutions: prebuilt sets of indicators, sources, breakdowns, dashboards, and data collection jobs for a product area (some still named "content packs", for example Performance Analytics Content Pack for Procurement Service Management). Activating a solution installs its data collector jobs; a solution's periodic job must be activated before it collects.
Licensing: without a paid Performance Analytics subscription, use is limited to 180 days of data collection (five months for monthly indicators) and specific ServiceNow-provided indicators (for example Complimentary Performance Analytics for Incident Management), and Data snapshots cannot be activated. Custom indicators and breakdowns need the subscription.
Implementation flow: identify the business questions and KPIs → choose or build indicator sources → define indicators → add breakdowns → set up data collection (historical once, then periodic) → build visualizations and dashboards → set targets and thresholds → grant roles.
KPI design tooling such as KPI Composer helps translate a business question into indicator and breakdown structure.

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

Roles: pa_admin and pa_data_collector (each equivalent to admin from a security perspective), pa_power_user (creates and manages indicators, breakdowns, bucket groups, and widgets), pa_target_admin and pa_threshold_admin (global targets and thresholds), pa_contributor (enters scores in scoresheets for indicators they contribute to), pa_analyst (text analytics keywords), pa_kpi_signal_admin, and pa_viewer (needed before Quebec, still on some upgraded instances). Users with no role can view dashboards shared with them, and any role can create dashboards. Grant least privilege.
Administration: All > Platform Analytics Administration holds indicators, sources, breakdowns, data collector jobs and job logs, properties, and diagnostics. The legacy Performance Analytics Admin Console is not available on net-new instances starting in Zurich.
Properties: PA properties control collection behavior, element limits, retention, and colors.
Solutions administration: install and activate solutions and their jobs. When a solution is upgraded, records with updates are installed but previously customized records are not overwritten, so review customized records against the new version.
Maintenance: monitor job logs, manage score and 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 data.
Automated = from an indicator source via a data collection job. Manual = typed or imported, no source. Formula = [[A]] / [[B]] math on other indicators, calculated when viewed, not collected. External = advanced, outside data.
Indicator source = facts table + conditions + Valid for frequency; collection queries once per source, so reuse sources.
Breakdown source = records from a table or database view (unique field, usually Sys ID) or a bucket group; it supplies the elements.
Breakdown mapping = the field (or script) on the indicator source that references the breakdown source, one per facts table.
Empty or non-matching values land in the Unmatched element (Label for unmatched).
Manual breakdown = elements and broken-down scores entered manually; no field mapping.
Breakdown matrix = two-breakdown combinations (Collect breakdown matrix); exclusions drop meaningless breakdown pairs.
Breakdown relation = navigation between elements (hierarchy or breakdown to breakdown), not a pivot.
Scores live in pa_scores_l1 and pa_scores_l2 (pa_scores is deprecated); snapshots in pa_snapshots.
Snapshot = record sys_ids behind a score; only automated indicators with Collect records; kept 183 days by default.
Historical collection = run On demand, once; deletes prior data for its periods and indicators; exclude breakdowns on changing fields.
Troubleshoot via job logs and job log details (run time per job, steps per indicator source).
KPI Details (Platform Analytics) = Analytics Hub (Core UI) = deep analysis of one indicator; replaced the detailed scorecard.
Target = goal; target color scheme = traffic-light coloring. Threshold = normal range plus email notification, dotted line. Trend line = direction; forecast = projection.
Data visualizations (Platform Analytics) replace PA widgets and reports (Core UI).
Core UI interactive filters do not filter PA widgets; Platform Analytics dashboard filters apply to visualizations on the same table or indicator breakdown.
KPI Signals = statistical change alerts on indicators; Spotlight = ranks records by weighted criteria.
Platform Analytics Solutions = prebuilt PA content per product area; activating installs collection jobs; upgrades do not overwrite customized records.
pa_admin / pa_power_user / pa_data_collector / pa_target_admin / pa_threshold_admin / pa_contributor; administration under All > Platform Analytics Administration (no Admin Console on net-new Zurich instances).