A user may be displaying a specific stand-alone report or a report which is part of a Dashboard or Homepage and find that the report is displaying less information than expected or possibly no data at all.
There are several reasons why this can occur, and this article will describe some of the most common such reasons as well as potential solutions or workarounds for the issue.
Cause and Resolution
There are several potential reasons for this to occur, and the following sections will detail some of these reasons and how this might be fixed:
Report Not Shared
The most common and obvious reason a report may not be viewable or accessible is that the report has not been shared with the users who are attempting access to that report (either by way of an individual user, a role or a group). By default, a newly created report will not be shared and therefore inaccessible to anyone except the report creator or users with the admin role. A report can generally be shared out on an individual user basis, shared with one or more groups or assigned to one or more Roles on the system.
Symptoms of this type of permissions issue will generally result in the report simply not appearing in a list or otherwise showing in any options in which a report might be opened or selected. In the case where such a report is added to a Dashboard or Homepage in which other users have access to the Dashboard or Homepage but not the report, the dashboard will display, in the location where that report would normally appear, a message indicating "Report visible only to a specific user or group".
To correct this issue, the owner of the report (or an administrator) should share that report to the appropriate individuals who should have visibility and access to that report. This can be performed directly from the sharing icon in the report display by the owner of said report.
Fewer Rows than Expected Displayed in List Reports
Another of the more common issues that might be reported with a report is that, in a List type report, fewer rows are appearing in the report than might be expected by the viewer. For instance, one user might find 100 rows in a list report, but another user, viewing that same report may see fewer or even no rows at all. In these cases in which one or more rows have been removed from the report, a message will also usually appear indicating some number of groups was removed from the list due to security constraints.
For instance, one user viewing a list report of active printers might encounter the following view of the report:
However, a different user viewing that same report might receive a much different result when zttempting to view it.
The usual cause for this issue is due to the fact that in a List type report, each row which is to be returned by the report is first compared against any read Access Control (ACL) records as defined on the source tables for that report.
Thus, for this example List report, the following ACL would be considered for each list row that might be displayed in that report.
To correct this issue, a new ACL may need to be created (or an existing ACL record updated) that would provide the necessary read permissions to the tables and fields for the users who might need to view this information. Modifying or creating a new ACL record will require an admin account which has been temporarily elevated to security_admin and as always, particularly when editing ACL's and other security-related objects in the system, extreme caution should be preserved.
Graphical Reports Showing Incomplete Data
Another fairly common issue which is sometimes encountered with viewership of reports is that a graphical type report (defined as any non List type report) may show an incomplete set of data, as compared to another user reviewing that same report.
This issue is caused by the fact that any Before Query Business Rules are performed on the data from the source table before a report is generated and rendered for its viewers. Thus, if any such applicable Business Rules are found on the source tables of that report, and limit the data based on permissions or similar criteria, any records that do not fulfill that criteria will not be considered for inclusion in the report. Thus, users with differing permission levels (due to group or role permissions particularly) may see the same report showing a vastly different result.
For example, say we have a report titled "All Incidents by Category" on the instance that might appear as follows for the creator of that report:
However, another user may then attempt to view the same report, and, upon viewing the report, this viewer describes seeing the report showing a much smaller subset of data, such as the following:
Investigating as to why there might be such a difference, we find that the source table for this report, Incident, has a Before Query Business Rule associated with it that will run on the report data before the display of the final report to an end user or rendering of that report on a Dashboard or Homepage.
Thus, for this example, we find that there is an out-of-box Before Query Business Rule running on the Incident table which limits the records which will be accessible to a specific user.
In this particular case, because this particular user is not a member of the itil role, not the original opener or caller of that Incident and not a member of that Incident's Watch List, this user will be unable to review any of those records. Because this user is the submitter of one such record, however, we do see that the report includes one such record which corresponds to that user. Checking the actual data that is being considered for this report, we do find that there is exactly one record that fulfills these specific requirements for this current logged in user and is thus included in the version of the report displayed for that user.
There are a few methods we could use to correct this type of issue. We could add the user to an appropriate role (as specified in the allowable Roles list for that Business Rule), or we could modify the Business Rule as needed to provide the necessary permissions for the user while at the same time retaining the security posture needed for the applicable data.
Similar to the previous issue described, Read ACL's on a specific record type can also limit access to specific records in a table which could also cause reports to display based on less data than might be expected for that report.
Note also, that although this particular issue is described in terms of graphic-based reports, On-Query Business Rules would also be applied to the rows returned in a List report. However, since these rows are often limited by ACL's, which are usually much more restrictive than Business Rules, this issue is usually less commonly encountered in reports of type List.
There are, of course, many other possible reasons why a report might be returning no data or less data than as would be expected, but the issues as described in this article are some of the more commonly encountered sources of reduced or no data appearing in a particular report and thus are often a solid starting point for troubleshooting and resolving issues in which the data returned in a report may seemingly be incomplete for any particular end user.