ServiceNow Report Source Explained

What a Report Source Is

A report source is a specification that tells ServiceNow what data to retrieve and display in a report. The source defines which table or tables contain the data, which fields to include, and how to filter and sort the data. Multiple reports can use the same source, or each report can have its own source. The source acts as a data definition layer between the report and the underlying tables.

When you create a report in ServiceNow, you choose a source. The source is typically a table or a view that exposes specific fields from one or more tables. The report then retrieves data from that source and formats it for display. If the underlying table structure changes, updating the source ensures that reports continue to work correctly rather than breaking due to schema changes.

Where Report Sources Live in the Platform

Report sources are defined in ServiceNow’s data layer and are visible through the Administration interface. Common sources include tables like incident, change_request, and request_item, which are the raw data tables that reports query. More sophisticated sources might combine data from multiple tables using joins or views, creating a unified data structure that reports can query without needing to understand complex relationships.

Custom report sources can be created to expose data in formats that are useful for specific reporting needs. A custom source might combine data from multiple tables, pre-calculate derived fields, or apply filters that enforce consistent business logic. Once a custom source is defined, multiple reports can use it, ensuring that those reports show consistent data.

The source definition includes field selections, allowing you to expose some fields while hiding others. This capability supports security by ensuring that sensitive fields are not available to all reports, and supports usability by showing only relevant fields in reports.

A Worked Example: Incident Report Source

The incident table in ServiceNow stores data about every incident: who reported it, when it was reported, who assigned it, what state it is in, and how long it took to resolve. An incident report source exposes the fields that are relevant for incident reporting: incident number, description, assignment group, assigned person, priority, state, created date, and resolved date.

A manager might create a report using this source to show incidents grouped by assignment group and priority, showing count and average resolution time. Another report might use the same source to show incidents by category and severity. A third report might filter to show only incidents that were not resolved within the service level target. All three reports use the same source, but display different aspects of the underlying incident data.

If a new field is added to the incident table, the source definition can be updated to include that field, and reports that use the source can then include it. This abstraction layer means that reports do not need to be rewritten when the underlying table structure changes.

Common Misunderstandings About Report Sources

A frequent misunderstanding is thinking that report sources are the same as database tables. Sources are specifications about what data to expose, while tables are where data is stored. A source might expose data from multiple tables, or expose selected fields from a single table. Multiple sources can pull from the same table, exposing different subsets of fields or applying different filters.

Another confusion is assuming that changing a report source affects existing reports. In reality, reports that already use a source are not automatically updated when the source is modified. However, if you change a source in ways that affect how reports use it, existing reports may need to be reviewed and adjusted.

Some organisations incorrectly assume that custom sources require technical development effort. While custom sources can be sophisticated, many organisations can create useful custom sources using ServiceNow’s configuration interfaces without needing to write code.

Designing Report Sources for Consistency

Well-designed report sources create consistency across an organisation’s reporting. If multiple teams need incident reports, defining a single incident report source and having teams build their reports on that source ensures that the reports use consistent definitions of fields and filters. This consistency makes it easier to compare reports across teams and understand organisational metrics.

Custom sources can enforce business logic. For example, a source might filter out incidents that are in certain states, or always include derived fields that calculate metrics relevant to your organisation. Once this logic is defined in the source, all reports using that source automatically apply the same logic.

Performance considerations apply to report sources. A source that requires complex joins or calculations may make reports slower. Designing sources that are efficient to query supports good report performance and ensures that reporting does not overload the system.

Why two reports on the same data disagree

A common reporting complaint is not that a number is wrong. It is that two numbers that should match do not. A service manager reads one open-incident count from a dashboard, a team lead reads a different count from a list view, and both are looking at the same table. The gap often comes from the report source: the set of fields, joins, filters and grouping rules that a report inherits or defines for itself. Each report built on its own source makes its own choices about which rows count, and nobody notices the divergence until a meeting depends on it.

For a reporting owner, the job is therefore less about building attractive charts and more about deciding which definitions are shared and which are local. That decision determines how many numbers the organization will argue about, and how long those arguments take to settle.

Choosing between a table report, a shared source and a trend indicator

There are three practical ways to get data into a report, and each suits a different question. The comparison below frames that choice.

Question being asked	Build directly on the table	Build on a shared source	Use a trend indicator
Who needs this number and how often	One person, occasional	Several teams, repeated	Leadership, reviewed over time
Does the definition of a row need to be agreed	No, it is a local question	Yes, the rows are shared	Yes, and the definition must not drift
Is history the point	Rarely	Sometimes	Yes, the change over time is the answer
Main risk	Silent divergence from other reports	A change to the source alters every report that uses it	Target and baseline set once, then never reviewed

A useful rule is that a source should be shared only when a second team would make the same definitional choice without being told. If the choice is genuinely local, a separate report on the table is cheaper to maintain and easier to retire.

What a viewer actually sees when a report runs

A report is evaluated under the access rules of the person viewing it. Table-level and field-level rules apply, so the same report can show fewer rows, or blank values, to a user in a different group. Reporting owners often build a report on their own screen, see the full result, and then share it, only to find that a regional group receives a smaller count. The cause is often an access rule rather than a fault in the report.

The practical response is to test the report as the audience. Open the shared report as a typical member of that group on a test copy, or ask someone from that group to read the count aloud. Compare it with the figure the owner sees. A difference is information, and it should be explained before the report is circulated.

Checklist before a source becomes shared

A shared source carries more responsibility than a local report, because its changes propagate. The following steps reduce the risk that the first wave of reports disagrees with the second.

1. Write the business definition of a single row in plain language, for example one incident, counted once, from the moment it is opened to its closure date.
2. Reconcile the source against a list view using the same filter, and record the count and the date of the check.
3. Confirm that every join is one-to-one, or document where it is one-to-many, because a multiplied join inflates totals silently.
4. Decide how time is handled, including which time zone grouping uses and whether the report counts by created date or by resolved date.
5. Name a source owner who approves changes to fields and filters, and state who is told when a field is renamed or removed.
6. Run the source as the most restricted audience it will be shared with, and record any rows or fields that differ from the owner view.

Symptoms of a source that has drifted

Drift is quiet. A source that was correct at launch can become wrong without any single change being obviously responsible. The following symptoms often point back to the source definition rather than to the reports that use it.

• Two reports built on the same source show different totals after one of them was filtered by a second field.
• A grouped total is larger than the sum of its groups, which usually means a join is returning rows more than once.
• A report that used to show a column now shows blanks, after a referenced field was changed upstream and the source was not reviewed.
• Reports disagree around the start or end of a month, which often points to time zone handling rather than data error.
• Users in one group report a different count from the owner, and the difference is traced to access rules, not to the data itself.

When a symptom appears, the fastest route is usually to compare the source definition with the list view it should match, rather than to rebuild the reports one by one.

When a report source is the wrong tool

A report source answers a question about current or recent records. It is not the right place for a question about how a measure has moved over many weeks, because it does not keep the history of a field’s values. For that, a trend indicator built on the same definitions is the better tool, and the two should be designed together so that the report and the trend cannot tell different stories.

A source is also the wrong tool for one-off investigations. A question asked once should be answered with a local report and then discarded, so that the shared definitions do not accumulate exceptions. Teams that promote every temporary report to a shared source end up with many almost identical sources, and reconciling them costs more than the reports are worth.

Questions reporting owners raise about sources

Can a source be changed without breaking existing reports?

Often yes, if the change only adds a field. Removing or renaming a field, or changing a filter, can alter the output of every report that depends on it. Treat those changes as a release, with a list of affected reports and a before and after comparison of their totals.

Why does a dashboard total differ from the same report run on demand?

A dashboard tile and a standalone report can disagree for three ordinary reasons: a filter applied to only one of them, a different time window, or a different viewer. The piece on common reporting challenges covers overcoming reporting obstacles and is a useful companion. Check the filter first, then the viewer, and only then the data. Many differences are explained by one of those three.

Should a source carry calculated fields?

Calculated fields in a source keep the arithmetic in one place, which helps consistency. They also hide the logic from people who only read the report. Document each calculated field in the source description, so a reviewer can see what it does without opening the definition.

Who should be allowed to create shared sources?

Keep creation with a small group that understands the table relationships and the access rules. Anyone can build a local report, but a shared source changes what many people see, so its author should be accountable for its reconciliation.