Free CIS-PA Practice Test Questions and Answers (2026) | Cert Empire Practice Questions

Historical data collection is a resource-intensive, one-time operation designed to populate indicators with data from a past period. It is not meant to be a recurring process. Therefore, the data collection job should be configured to run either 'Once' at a scheduled time or 'On Demand' when manually executed by an administrator. Setting a recurring schedule like daily or weekly for a historical job is incorrect and inefficient.

B. Weekly: This is a recurring schedule and is inappropriate for a one-time historical data load.

C. Daily: This is the standard schedule for ongoing, daily data collection, not for collecting a historical backlog.

D. Monthly: This is a recurring schedule and is not suitable for a one-time historical collection.

- ServiceNow Product Documentation, "Collect historical data." The procedure explicitly states for the 'Run' field to "Select On Demand or Once." It also includes a warning: "Do not set up a recurring historical data collection job."

- ServiceNow Performance Analytics (PA) Fundamentals courseware, Module: "Data Collection," Topic: "Historical Data Collection."

An indicator, whether automated, manual, or formula-based, is fundamentally a Key Performance Indicator (KPI) that measures performance over time. It collects data points (scores) on a recurring schedule (e.g., daily, weekly). This collection of scores creates a time series that allows for trend analysis, showing whether performance is improving, declining, or remaining static. An Automated Indicator specifically uses a data collection job to gather these scores automatically from a ServiceNow table based on specified conditions.

B. A process summary at a single point in time is a report or a snapshot, not a trended indicator.

C. A subcategorization of an indicator that provides more granular views of scores is the definition of a breakdown.

D. A scheduled job that collects data is the mechanism for an automated indicator, but it does not describe what the indicator is.

1. ServiceNow Product Documentation, "Performance Analytics indicators," Performance Analytics and Reporting, Washington D.C. release. (Defines an indicator as "a business metric used to measure performance over time").

2. ServiceNow Product Documentation, "Create an automated indicator," Performance Analytics and Reporting, Washington D.C. release. (Describes an indicator's purpose as tracking data trends over time, with automation being the method of score collection).

A Breakdown Source defines the unique elements for a breakdown (e.g., all possible assignment groups). This is configured by specifying a 'Facts table,' which is the source table containing the elements (e.g., the sysusergroup table). A 'Field' on that table, most commonly the sysid field, is then selected to ensure each element is uniquely identified. This structure allows Performance Analytics to correctly map indicator scores to the distinct breakdown elements during data collection.

A. Related List Conditions are used to filter breakdown elements, not to define their base table or unique identifier.

C. Indicator Configuration links an indicator to a breakdown but does not define the breakdown's source elements.

D. Manual Indicators and Scoresheets are used for manual data entry and are not related to defining breakdown sources.

- ServiceNow Product Documentation, "Create or modify a breakdown source". The configuration form explicitly includes the "Facts table" and "Field" attributes. The documentation describes the "Field" as the one "that contains the unique values for the breakdown elements, such as sysid."

Fiscal Calendars in Performance Analytics allow organizations to define custom time periods that align with their financial reporting schedules, which may differ from the standard Gregorian calendar. This functionality enables the creation of reports and visualizations grouped by fiscal months, quarters, or years. By creating a custom fiscal calendar and associating it with a calendar group, users can apply these fiscal periods to widgets and analytics hubs, ensuring that performance data is presented in a context that is relevant to the business's financial cycles.

A. Gregorian Calendars represent the standard calendar year (January-December) and are the default, but not the specific feature for custom fiscal periods.

C. Timecard Calendars are part of the Time Card Management application and are used for tracking work hours, not for PA data visualization.

D. Business Calendars are used in applications like SLA Management to define working hours and holidays, not for defining fiscal reporting periods in PA.

- ServiceNow Product Documentation, "Fiscal calendars for Performance Analytics," docs.servicenow.com. (This document directly describes the purpose and use of Fiscal Calendars for visualizing data over fiscal periods.)

- ServiceNow Performance Analytics (PA) Fundamentals courseware. (Covers the concept of using Fiscal Calendars for business-aligned reporting.)

When creating a breakdown based on predefined ranges or "buckets," such as the age of a task (e.g., 0-5 days, 6-10 days), the breakdown source must point to the table that defines these buckets. In ServiceNow Performance Analytics, the Bucket [pabuckets] table serves this purpose. It stores the start and end values for each range. A scripted breakdown mapping is then used to evaluate a record's age and assign it to the correct bucket defined in the [pabuckets] table.

A. The Task [task] table is the source for the indicator's data, not the source for the age range definitions (buckets).

C. A Bucket Group is a container for related buckets, but it is not a table that can be selected as a Facts table.

D. The Choice [syschoice] table is used for breakdowns based on choice list fields, not for calculated age ranges.

1. ServiceNow Product Documentation, "Create a breakdown for age buckets," Performance Analytics and Reporting, Washington D.C. release. (States, "For the Facts table, select Bucket [pabuckets]").

2. ServiceNow Developer Documentation, "PA Bucket [pabuckets]," API and Schema, Washington D.C. release. (Describes the schema for the pabuckets table, which contains fields for start and end values of a range).

Historical data collection jobs capture daily snapshots of indicator scores and their breakdowns. For this data to be meaningful and accurate over time, the breakdown values for a given record should be static. The "Age" of an open incident is a dynamic value that changes every day the incident remains open. Collecting historical data on a volatile breakdown like Age would result in the same incident appearing in different age buckets on different days, rendering trend analysis inaccurate. Therefore, breakdowns based on dynamic, time-sensitive calculations like Age should be excluded.

B. Location: The location associated with an incident is typically a static attribute that does not change during its lifecycle.

C. Category: The category of an incident is generally set once and remains static, making it suitable for historical collection.

D. State: For an indicator on "open" incidents, the state is fixed by the indicator's conditions, making it a stable characteristic for collection.

- ServiceNow Performance Analytics (PA) Advanced courseware. This training explicitly covers the concept of avoiding volatile breakdowns like Age for historical data collection to ensure data integrity.

- ServiceNow Product Documentation, "Breakdowns". Best practice guidelines emphasize using breakdowns based on fields that do not change over time for the same record when collecting historical data.

Formula indicators do not perform real-time calculations when a widget is viewed. Instead, their scores are calculated during a scheduled data collection job. The formula uses the already collected and stored scores of other indicators as input. The resulting score for the formula indicator is then pre-calculated and stored in the Performance Analytics scores tables, ensuring fast retrieval and display on dashboards.

A. Real-time calculation on-demand would be highly inefficient for trend analysis and would negatively impact performance.

B. The data is not temporary; formula indicator scores are stored permanently in the scores tables just like other indicator scores.

D. While calculation is often daily, it is determined by the job schedule and is not inherently restricted to a daily frequency.

- ServiceNow Product Documentation, "Create a formula indicator". The documentation states, "The scores for a formula indicator are not collected from your instance data but are calculated from other indicators' scores... Scores for formula indicators are generated during data collection."

- ServiceNow Performance Analytics (PA) Advanced courseware, Module: "Advanced Indicators". This module explains that formula indicators are processed by collection jobs and their scores are stored in the pascores tables for historical analysis.

The "Field value duration" metric type is specifically designed to measure the amount of time a particular field on a record holds a specific value. In this scenario, the goal is to track the duration for which the assignmentgroup field on an incident record is set to a certain group. This metric type automates the calculation of this duration, making it the most direct and appropriate choice. It works by creating records in a metric table (metricinstance) that capture the start time, end time, and duration for each period the condition is met.

B. Script calculation: While a script could achieve this, it is unnecessarily complex for a standard requirement that is directly supported by a built-in metric type.

C. State change: This metric type is used to measure the duration between two different values in the state field, not the duration a different field holds a value.

D. Assignment group: This is the name of a field on the incident table, not a type of metric definition.

1. ServiceNow Product Documentation, "Metric definition types." The documentation explicitly describes the "Field value duration" type as the method to "Create a metric that measures the duration that a field has a specific value."

2. ServiceNow Performance Analytics (PA) Advanced Courseware, "Module: Metrics," Section: "Creating Metric Definitions." This section provides examples, including tracking assignment group duration using the "Field value duration" type.

The error message "The number of breakdown elements for this breakdown source exceeds the instance limit" indicates that the query for the breakdown source is returning too many unique records. The best practice to resolve this is to refine the breakdown source by adding or modifying its conditions. This reduces the number of elements to a manageable level below the system property limit (com.snc.pa.dc.maxbreakdownelementslimit), ensuring data collection jobs can complete successfully and efficiently without degrading system performance.

A. Increasing the system property limit is not recommended as a first step because it can cause significant performance issues during data collection.

B. Simply enabling "DC active" does not change the number of elements the source returns and will not resolve the underlying issue.

C. Deleting and recreating the breakdown source is an unnecessary and ineffective action; the new source would still query the same data and produce the same error.

1. ServiceNow Product Documentation, "Breakdown source properties and limits," Doc ID: 0651385d870330105bde3a973ebb351c. This page states, "To avoid this error, apply a filter to the breakdown source to reduce the number of elements."

2. ServiceNow Now Create, "Performance Analytics & Reporting - Data Collection & Cleanup," Section: Breakdown Element Limits. This guide recommends filtering breakdown sources as the primary solution for exceeding element limits.

A breakdown mapping creates the relationship between an indicator's facts table and a breakdown source. When indicators are based on different facts tables (e.g., Incident and Problem), but you want to use the same breakdown (e.g., Assignment Group), you must create a separate breakdown mapping for each relationship. One mapping will link the Incident table to the breakdown source, and a second mapping will link the Problem table to the same breakdown source.

A. Indicators based on different facts tables cannot, by definition, use the same indicator source, as an indicator source is tied to a single table.

B. You create one breakdown record (e.g., "Assignment Group"). You do not create multiple breakdown records for the same logical grouping.

C. A mapping script is a method within a breakdown mapping, not the primary solution. The fundamental requirement is creating the mapping record itself.

1. ServiceNow Product Documentation, "Create a breakdown mapping". The documentation explains, "Breakdown mappings relate a breakdown source to an indicator source. You must have at least one mapping for a breakdown to work with an indicator." This implies a mapping is needed for each indicator/facts table context.

2. ServiceNow Performance Analytics (PA) Fundamentals courseware, "Breakdowns and Mappings" module. This training material explicitly covers the scenario of using one breakdown across multiple tables, stating that a unique pabreakdownmappings record is required for each facts table.

An Index Indicator is a weighted average of several contributing indicators, designed to measure an overall process health. The score is calculated as a percentage. The ideal state or goal for this composite score is 100%. Therefore, the target for the index indicator, as well as its contributing indicators, should be set to 100. The desired direction of performance is to increase this score over time, so the direction must be set to Maximize. This configuration ensures that analytics and visualizations correctly represent improvement as the score approaches 100.

A. 0% and Maximize: A target of 0% is incorrect; the goal is to achieve a perfect score of 100%, not zero.

B. 100% and Minimize: The direction should be Maximize, as a higher index score indicates better performance. Minimize would be incorrect.

C. 0% and Minimize: Both the target and the direction are incorrect for a standard index indicator configuration.

- ServiceNow Product Documentation, "Create an index indicator". In the procedure section, step 11 states: "For the index indicator and for each of the contributing indicators, set Direction to Maximize. Set a target with the value 100."

Performance Analytics Content Packs are activated in the same way as other ServiceNow applications or plugins. The correct navigation path is to go to the list of all available applications, find the desired content pack, and install or activate it. This process is managed through the instance's application management module, not within the Performance Analytics application menu itself. Activating a content pack installs all the associated components like indicators, breakdowns, and dashboards.

A. The path Performance Analytics > Activate Solution does not exist in the base ServiceNow platform for activating content packs.

C. The path Performance Analytics > Add Content Pack is not a standard navigation path for installing or activating content packs.

D. The Content Management application is used for building and managing service portals and is unrelated to activating Performance Analytics content packs.

1. ServiceNow Product Documentation, "Install Performance Analytics and Reporting," section "Activate Performance Analytics." The documentation specifies that solutions are activated as plugins from the System Applications > All Available Applications > All module.

2. ServiceNow Developer Documentation, "Application installation," describes the standard process for installing applications from the ServiceNow Store or activating plugins, which applies to content packs.

A formula indicator is a virtual indicator whose value is produced by applying arithmetic or statistical expressions to a limited set of existing automated indicators; ServiceNow limits this set to a maximum of five source indicators.

A. Aggregates such as COUNT or SUM are produced directly by automated indicators, not by formulas.

C. Formula scores are recalculated during data collection or a manual recompute, not only when viewed.

D. Formula expressions operate on other indicator values, not on threshold definitions.

1. ServiceNow Product Documentation – “Create a formula indicator”, Paris-Utah releases, section ‘Define the formula’, paragraph 2: “You can combine up to five existing indicators in one formula.”

2. ServiceNow Performance Analytics Best Practices Guide, v21.2, p.15, “Automated vs. Formula indicators”.

A scripted breakdown mapping is required when the logic to associate a record from an indicator source with a breakdown element is too complex for a standard field-to-field mapping. This occurs when there is no direct relationship or when the value must be derived or calculated. For example, mapping an incident to an age bucket requires a script to calculate the age and determine the correct bucket, as no single field on the incident record directly represents this.

B. Mapping to a Sys ID is a standard configuration. You map a reference field on the source table to the sysid field on the breakdown source.

C. Database views are supported as indicator sources, and standard field mappings can be used if the required field is present in the view.

D. Dot-walking to a related field is a standard, non-scripted feature of breakdown mappings, allowing you to map fields from related tables.

- ServiceNow Product Documentation, "Create a breakdown mapping." Performance Analytics and Reporting. This document states, "If no direct mapping between the indicator source and the breakdown source is available, create a scripted mapping."

- ServiceNow Performance Analytics (PA) Fundamentals Courseware, Module: "Breakdowns," Section: "Breakdown Mappings." The course explains that scripts are the solution for complex mapping logic where direct field or dot-walked mappings are insufficient.

The Target record form includes a 'Review date' field. This field is specifically designed to schedule a future date for the evaluation of the target's performance and progress. While the 'End date' marks the conclusion of the target period, the 'Review date' serves as a formal reminder or trigger for a performance assessment, making it the recommended evaluation date.

A. Improvement Date: This is not a standard field on the Target form in Performance Analytics.

B. Baseline Date: This date is the starting point from which improvement is measured, not the date for evaluation.

C. End Date: This is the date the target becomes inactive, but evaluation may be scheduled before or after this date.

- ServiceNow Product Documentation, "Create a target," Target form fields table. The documentation explicitly defines the 'Review date' field as the "Date on which you want to review the target."