Part 7 Full Quiz — Reporting & Analytics

B is correct. A Bar/Column chart is ideal for comparing counts or aggregates across categories — in this case, incident counts per assignment group. Each bar represents one group. A Line report (C) requires a Date/DateTime field for the X-axis and shows trends over time. A Heat Map (D) shows value intensity across TWO categorical dimensions. A List report (A) shows individual records, not aggregated counts per group.

B is correct. This is a classic exam trap. A ServiceNow Line report requires a real Date or DateTime type field for the X-axis — not a string/text field that happens to contain month names. ServiceNow uses the Date field to calculate time-series intervals (daily, weekly, monthly, etc.). Using a text "Created Month" field will either fail to render or produce incorrect results. Always ensure the date field is a proper Date/DateTime type in the schema when building Line reports.

B is correct. A Pivot Table is a grid (matrix) report where rows represent one dimension (Priority), columns represent another (Category), and each cell shows the aggregated value (count). This is the classic Excel-like cross-tabulation. A Heat Map (C) is similar but uses color intensity instead of numbers and is better for showing relative scale across two dimensions. A List report (D) shows individual records, not aggregates. A stacked bar (A) approximates this but is not a true two-dimensional grid.

B is correct. Report Conditions act as a WHERE clause — they filter which records are included in the report's dataset before any grouping or aggregation. "Priority = 1" means only Priority 1 incidents are counted. This is equivalent to a list view filter condition. It is not security-based (A), not an automation trigger (C), and not a column formula (D). Setting the right conditions is fundamental to building accurate reports.

B is correct. A Left Outer Join returns all records from the PRIMARY (left) table regardless of whether a match exists in the secondary table. For non-matching rows, secondary table fields are null. Inner Join (D and A) would only return rows with matches in BOTH tables — excluding incidents with no SLA. Right Outer Join (C) would return all secondary table (SLA) records. Use Left Outer when you want to see ALL primary records, including those with no related data.

B is correct. Database Views are strictly read-only. They are virtual (not physical) database constructs that exist only for querying/reporting. You cannot: write data through a view, create records in a view, trigger Business Rules on a view, or add ACLs specific to the view. All Business Rules must be on the underlying real tables (incident, task_sla, etc.). Attempting to add a Business Rule to a view record is not supported. This is a fundamental limitation of the DB View design.

B is correct. In a Database View, the primary table (also called the "left" table in SQL terms) is the anchor of the join. With a Left Outer join, every row from the primary table appears in the result set — even if no matching row exists in secondary tables. The primary table determines which records "drive" the report. In this example, all Incident records appear; sys_user (assigned to) fields may be null if unassigned. Choosing the right primary table is critical for Left Outer vs Inner join behavior.

C is correct. Database Views are 100% read-only. There is no "Allow Writes" option (D). To update data shown in a view, you must navigate to and edit the underlying base table record directly (e.g., open the actual Incident record, not the view row). This read-only nature is intentional — views are for reporting, not data entry. The view does not even have a form layout configured for editing purposes.

B is correct. This is a heavily tested exam trap. Interactive Filters only affect widgets that use the SAME source table as the filter. Since the filter is on the Incident table (or whatever table the filter's source field is from), only Incident-based widgets (Widget A) are affected. The Problem table widget (Widget B) is completely unaffected regardless of being on the same tab or having the same field. If you want to filter both, you need separate Interactive Filters configured for each table.

B is correct. A Scheduled Report sends the report output via email to specified recipients at the configured schedule. The email includes the report as an attachment (PDF, Excel, CSV) and/or a direct link to view it in ServiceNow. It does not save new report versions (A), create dashboard widgets (C), or write to the file system (D). This is the primary way to push report data to stakeholders who need periodic updates without manually running reports.

B is correct. Dashboard Sharing lets the dashboard owner control who can access the dashboard and at what permission level (Can View vs Can Edit). You can share with specific users, groups, or roles. This is separate from Dashboard Cloning (copying to another instance - A). Real-time co-editing (C) is not a ServiceNow feature. While dashboards CAN be made public, that is a specific setting, not the general definition of sharing (D).

B is correct. This is the core PA vs Reports distinction. A standard report runs against the current state of data — if you run it today, it shows today's data (or filtered past records, but as a single snapshot). Performance Analytics periodically collects and stores scores (snapshots over time). This means you can graph "incidents open on the 1st of each month for 24 months" — a true time-series trend. Without PA having collected data historically, this trend view is impossible.

B is correct. This is a critical exam trap. PA does NOT retroactively collect historical data. When you configure a PA Indicator today, collection begins today. The 12-month trend chart would only have today's data point — nothing for the prior year. To build historical trend data, PA must have been collecting scores for those periods. This is why PA requires a long-term commitment — you must start collecting early to have historical data later. There is no retroactive backfill feature in standard PA.

B is correct. The PA hierarchy: Indicator — defines WHAT is measured and HOW (e.g., "Count of Open Priority 1 Incidents"); Score — a collected data point at a specific time for that Indicator (e.g., "On June 1, there were 47 open P1 incidents"); Breakdown — a dimension that segments a Score (e.g., by Assignment Group, showing "Network Team: 12, Desktop Team: 8, etc."). Breakdowns add granularity to Scores; Scores are instances of Indicators over time.

B is correct. A PA Breakdown defines a segmentation dimension (like Assignment Group, Priority, Location). When applied to an Indicator, PA collects separate score values per breakdown element — one score per group per time period. This enables comparison: "How did each Assignment Group perform on this metric over time?" without creating separate Indicators (D) for each group. Creating N Indicators for N groups (D) is technically possible but is not the scalable, designed approach — Breakdowns are.

C is correct. Database Views (Part 1 Topic 3) create virtual read-only joined tables. The Report Builder treats the view as a flat table with columns from both joined tables. Import Sets (A) are for data ingestion. Business Rules (B) create maintenance burden by denormalizing data — every CI change requires a Business Rule fire. GlideRecord (D) is a scripting API, not a declarative reporting configuration.

C is correct. Performance Analytics (Part 7 Topic 4) is ServiceNow's dedicated time-series platform. PA Indicators capture metric values on a collection schedule and store them, enabling trend visualization over weeks or months. CMDB Health KPIs (Completeness, Correctness, Compliance from Parts 5-6) can be defined as PA Indicators. Foundation Dashboards (B) show the current snapshot — they don't store historical series. Standard Reports (A) query current data and can't show how a metric changed over time.

B is correct. CSDM has distinct layers. cmdb_ci_business_app (Design domain) represents the business concept: ownership, cost center, business capability. cmdb_ci_service_auto (now 'Service Instance' in CSDM 5) is the technical service map created by Service Mapping. The Foundation Dashboard coverage widget checks whether Business Applications exist and are linked to their Application Services. 0% means the business layer is missing — admins must manually create Business Application CIs and link them. This connects Part 7 reporting with Part 5 CSDM.