ServiceNow reporting and Performance Analytics interview questions

Reporting comes up in almost every ServiceNow admin and consultant round, usually late in the interview when the panel has finished with scripting and wants to know whether you can talk to a business stakeholder. The questions look easy. They are not, because the panel is listening for one specific thing: do you know that a report and Performance Analytics answer two different kinds of question. This post works through nine questions from our question bank, four on reporting and five on Performance Analytics, with the configuration detail an interviewer expects behind each one.

Reporting questions

What are reports?

A report in ServiceNow is a saved query against a table, presented in a visual format. You pick a data source, apply conditions, choose how the records are grouped and aggregated, and choose a type such as bar, pie or list. The report definition is stored in the sys_report table. Nothing is copied anywhere. Every time somebody opens the report, the platform runs the query again against live data and renders the result.

That last sentence is the whole answer in an interview. A report is a live window on a table. Open the same incident report at 10am and at 4pm and you get different numbers, because incidents were created and closed in between.

You build reports in the Report Designer, which walks through a fixed set of steps:

• Data chooses the table, or a report source record when the same filtered set is reused by several reports
• Type chooses the visualisation
• Configure sets group by, stack by, the aggregation such as count, sum or average, and the filter conditions
• Style controls colours, legend and axis labels
• Format controls sizes, decimals and titles

Two details separate a candidate who has built reports from one who has read about them. First, the data source can be a table, a database view or a report source, and a database view is how you report across two tables that are related but not in a parent-child hierarchy, such as incident joined with the task SLA table. Second, grouping is limited by what is on the record. If the business asks for incidents grouped by region and region exists only on the caller's company record, you need a dot-walked field, a database view or a field on the incident populated at creation. Say that in the interview and you sound like somebody who has actually been asked for this report.

Types of reports?

There is a long list in the type picker. No interviewer expects all of them. They expect you to name the common ones and, more importantly, to say when each is the right choice. Group them by the question they answer.

The judgement question sits behind this list. A pie chart with fourteen slices is unreadable, so anything with many categories goes to a bar chart. A single score is the right answer when a manager wants a number on a wall, not a chart. A list report is the right answer when the user's next action is to open the record, because charts cannot be worked from.

One more point worth making. A line chart built on a date field shows when records were created, not how the backlog stood on each of those days. If the stakeholder wants the second thing, a report cannot give it to them and you need Performance Analytics. Saying this at the report types question, before it is asked, is what a strong candidate does.

Difference between report and dashboard?

A report is one visualisation of one query. A dashboard is a container that arranges many widgets on a canvas, where most of those widgets are reports. They are separate records with separate sharing, and mixing them up is a common slip.

The practical difference is the interactive filter. On a dashboard you can drop a filter for assignment group at the top, and every widget on that tab reshapes to the selected group. You cannot do that with a set of standalone reports. That is the reason managers want dashboards rather than a folder of links, and it is the answer that shows you have built one for a real review meeting rather than read the definition.

Dashboards also support tabs, so a service desk dashboard can carry a volume tab, an SLA tab and an ageing tab without any of them competing for space. Keep the widget count per tab low. Every widget runs its own query when the dashboard loads, and a dashboard with twenty widgets on a large table is a performance complaint waiting to happen.

What is scheduled report?

A scheduled report is a job that runs a saved report on a schedule and emails the output to a set of recipients. The definition lives in the Scheduled Reports table, sysauto_report, which extends the base scheduled job table. The record points at the report, sets the run frequency such as daily, weekly, monthly or periodically, sets the output format such as PDF, CSV, Excel or an inline image, and lists the recipient users, groups and email addresses.

This is the answer people give. Then the interviewer asks the second question, and this is where most candidates stop having anything to say.

Who sees what. A scheduled report generates its output as one user, then sends that single output to everybody on the recipient list. The report is produced under the access rights of the run-as user, not of each recipient. So a schedule set up by an admin and sent to a group of business users can put rows in front of people who would never see those rows if they opened the report themselves. This is a genuine data governance issue on real projects, and naming it is the difference between a textbook answer and an experienced one.

When it should not run. The base scheduled job record carries a conditional option, so you can set a condition that decides whether a given run goes ahead. Use it when the business does not want an empty attachment landing in their inbox every morning.

Debugging one. Our trainers rate this question higher than the definition, because it separates the two groups instantly. The panel says the scheduled report did not arrive, what do you check. Work through it in order:

1. Is the schedule record active, and does the next action time show a future date? A job with a blank or past next action is not queued.
2. Did it run? Check the scheduled job execution history for that record.
3. Did the report return rows? An empty report often means the condition references a value that no longer exists, such as a retired assignment group.
4. Did the email get generated? Check the outbound email log for the record, filtered by the recipient.
5. Is email sending switched on for the instance? On sub-production instances outbound email is usually disabled, and the message sits in the log as send-ready or skipped forever.
6. Is the recipient's notification preference or email address the problem, rather than the report at all?

A candidate who can walk that path is showing the panel that they have supported reporting in production. A candidate who can only define the term is showing the opposite.

What the interviewer is actually checking on reporting

• Whether you know a report runs live against the table each time it is opened, with no stored history
• Whether you choose a report type for the question being asked rather than for how it looks
• Whether you understand that dashboards add interactive filters and shared context, not just layout
• Whether you have debugged a scheduled report that did not arrive, not just created one
• Whether you spot the access risk in a scheduled report that is generated once and mailed to many

Access controls still apply to report data

This sits behind several of the questions above and panels ask it directly as a follow-up, so treat it as part of the reporting answer.

Yes. Reports are not a way around security. When a report runs, the query passes through the same read access controls and the same before-query business rules as a list view of that table. A user sees counts and rows built only from records they are allowed to read. Two people can open the same report at the same moment and see different totals, and that is correct behaviour, not a bug.

Field-level access controls apply in the same way. If a user cannot read a field, they cannot group, filter or aggregate on it in a report, and the field will not be available to them in the designer.

Sharing a report is separate from granting data access. The Share action on a report gives somebody visibility of the report definition. It does not give them any rights over the underlying table. Share an incident report with a user who has no read access to incident and they will open it to an empty chart. Conversely, restricting who a report is shared with is not a security control, because anybody with access to the table can build the same report themselves in two minutes.

The two exceptions worth naming are the scheduled report case described above, where output is generated once under one user's rights, and reports published to a public page, where the data leaves the access control model entirely. Both should be reviewed before go-live.

Performance Analytics questions

What is Performance Analytics?

Performance Analytics is the ServiceNow application that collects and stores scores on a schedule so you can see how a measure has moved over time. It does not query your data when you open it. It queries your data every night, writes a score for that day, and then shows you the stored series.

That is the whole idea. A report is a photograph of now. Performance Analytics is a time series that keeps accumulating whether anybody is looking or not.

The consequence matters more than the definition. Once a record changes, the old value is gone from the record. An incident that was P1 last Tuesday and was downgraded to P3 on Wednesday now reads P3 everywhere. No report you write today can tell you how many P1 incidents were open last Tuesday, because that fact no longer exists in the table. Performance Analytics captured the count on Tuesday night and still holds it.

Our trainers see the same failure here every batch. The candidate gives a clean memorised definition, the panel says give me a real example from your project, and the answer collapses. Have one ready. A service desk manager wants to know whether the change to the assignment rules in July reduced reassignment counts. That question needs a measurement from before July, which means Performance Analytics was collecting before July. You cannot go back and get it from a report.

Note also that Performance Analytics is licensed separately from platform reporting, with some content available under specific subscriptions. Mentioning that you checked the entitlement before designing a solution reads as consulting experience.

What is an Indicator?

An indicator is the thing being measured. It is the definition that says which records to count and how to reduce them to one number for each period.

An indicator is built on an indicator source, which is a record holding the table and the conditions that define the set of facts. For example, a source called Resolved incidents points at the incident table with a condition on state. Several indicators can share one source, which is why the source is a separate record.

The indicator itself adds:

• Aggregate, such as count, sum, average, maximum or minimum
• Field, when the aggregate needs one, such as averaging the resolve time
• Frequency, usually daily, weekly or monthly, which sets how often a score is written
• Direction, meaning whether a higher score is good or bad, which drives the colour of the trend
• Unit, target and thresholds, which drive the display and any alerting

There are three kinds you should be able to name. Automated indicators collect from an indicator source on a schedule. Formula indicators derive a score from other indicators, for example first call resolution as resolved at first contact divided by total resolved. Manual indicators take a number that somebody types in, used where the data does not live in the platform at all, such as an audit score.

The trainer's warning applies here. Interviewers go five levels deep on anything you claim to have built. Which indicator, which source table, what condition, why that aggregate rather than another, what was your part in it. An indicator you can name but cannot take apart sounds invented, and the panel has heard it before.

What is a Breakdown?

A breakdown is a dimension you slice an indicator by. If the indicator is open incidents, the breakdown might be assignment group, priority or category, and the platform then stores a score for each element of that breakdown as well as the overall score.

The structure mirrors indicators. A breakdown source defines where the elements come from, usually a field on the fact table, sometimes a related list or a script. The breakdown record then names the dimension and points at that source. You attach breakdowns to an indicator, and from that point the data collection job writes one score per breakdown element per period.

Two practical points are worth raising before the interviewer raises them.

First, breakdowns multiply the collection work and the stored rows. An indicator with three breakdowns of twenty elements each is writing a lot more than one score a night. Attaching every available dimension to every indicator is the standard way to make data collection slow and to fill the score tables, so you attach what will actually be looked at.

Second, breakdowns can be combined at view time. A user looking at a scorecard can apply assignment group and then priority within it, provided both breakdowns were collected. They cannot add a dimension after the fact and see history for it. The collection had to have been configured earlier. This is the recurring theme of the whole subject and it is what the panel is testing.

What is Data Collector?

The data collector is the scheduled job that actually gathers the scores. It runs on a schedule, typically overnight, reads each active indicator, runs the query defined by the indicator source and conditions, computes the aggregate for the period, and writes the resulting score into the Performance Analytics score tables. It does the same for every breakdown element attached to the indicator.

Some further points an interviewer will look for:

• Snapshots. When collection is configured to record them, the job also stores which record IDs made up each score. That is what allows a user to click a point on a chart from three months ago and see the actual records behind it. Without snapshots you have the number and nothing underneath it.
• Frequency and run window. Collection runs against frequencies, so a weekly indicator writes one score per week. The job window matters, because a large number of indicators and breakdowns can take hours, and it should sit outside business hours and outside the backup window.
• Historical data collection. You can run a separate historical collection to backfill scores for past periods, but only for what can still be derived from data that exists today. Where a field has been overwritten since, the backfilled score is an approximation rather than what was actually true then. Say this clearly in an interview, because the panel often expects a candidate to claim backfill solves everything.
• Failures. If the job does not run, no score is written for that day and the series simply has a gap. Monitoring the collection job is part of running Performance Analytics in production.

Difference between Reporting and Performance Analytics?

This is the answer the round is decided on. Everything above is background for it. Give the comparison cleanly.

The sentence that settles it: you cannot answer "was our mean time to resolve better last quarter than this quarter" with a report. A report can average the resolve time of incidents resolved in a date range, which looks similar, but it is computed from the records as they stand today. Records reopened, reassigned or recategorised since then have changed that average, and any record that was purged or archived has left it entirely. Performance Analytics wrote the score at the close of each period and that score does not move.

The reverse also holds and candidates forget it. Do not propose Performance Analytics for everything. If the manager wants the list of tickets breaching SLA this afternoon so the team can work them, that is a report. Performance Analytics would tell them the breach count last night, which is no use to somebody trying to fix it now.

The scorecard and the Analytics Hub

The scorecard, presented as the Analytics Hub in recent releases, is the detailed single-indicator view. Open one indicator and you get the time series chart of its collected scores, the target and threshold lines, the direction of the trend, comparisons against an earlier period, and the breakdowns available to slice it.

Three things make it more than a chart. You can change the breakdown from the scorecard itself and the whole series reshapes, without anybody rebuilding anything. You can drill from a point on the line to the records that made up that score, when snapshots were collected. And you can compare a period against the equivalent earlier period, which is exactly how quarterly reviews are run.

Performance Analytics dashboards are built from PA widgets that point at indicators, which is a different widget type from the report widgets on an ordinary dashboard. Knowing that the two widget families are separate, and that a PA dashboard reads stored scores while a report widget runs a live query, is a small detail that lands well.

What the interviewer is actually checking on Performance Analytics

• Whether you can state the collection idea clearly: scheduled collection into stored scores, not a live query
• Whether you know the build order of indicator source, indicator, breakdown and collection job
• Whether you understand that history begins when collection begins, and what backfill can and cannot recover
• Whether you can name a real business question that a report genuinely cannot answer
• Whether you know when not to use Performance Analytics, which is the check on whether you have used it

Closing

Reporting questions reward candidates who have sat with a stakeholder and turned a vague request into a chart that answers it. Performance Analytics questions reward candidates who understand that measurement has to be set up before the period you want to measure. Prepare one real example for each: a report you built and why you chose that type, and an indicator you configured and what decision the trend supported. Then be ready for the follow-up, because the panel will keep going until either the detail runs out or you do.

Our ServiceNow training covers reporting and Performance Analytics as build work on a live instance, so you leave with configurations you can describe end to end rather than definitions you can repeat.