Note: In v6.1 of Elements, the Reporting Hub was introduced. From that version, more and more types of report are being steadily migrated away from the management interface described in the older Managing registered reports article, to the new Reporting Hub.

This article continues from the Introduction to the Reporting Hub article to discuss the options available in the Reporting Hub for managing reports.

Much of the functionality of the Reporting Hub is self-explanatory. We provide additional helpful details about some of the functionality here where we think it might be useful.

Particularly after an upgrade to Elements, it is recommended to test all custom reports as a standard part of your institution's upgrade project plan. To help with this, the Reporting Hub offers the ability to ask the system to run tests on formatted reports in bulk.

Note: This functionality is not available for dashboards, which must be tested manually by viewing them. Any dashboard that is selected will be ignored when the Run Tests button is clicked.

After selecting the desired reports using standard filtering and selection functionality, click the Run Tests button. This will cause all formatted reports in the selection to be scheduled for immediate test. The system will attempt to run each of the selected reports in the background using automatically chosen parameter values (where a report has parameters).

Until the tests have completed, something like the following status will be shown on the reports scheduled for tests.

The resultant output report file is discarded, but the success or failure of the test run is recorded in the system. On a successful test, no further feedback is shown on a report. On a failure, a suitable message is shown against the report to any user with the right to manage the report. It typically describes the reason why the report could not be run.

Once the issue has been fixed and the report has either been successfully re-tested or successfully manually run, the error message will be removed by the system.

The tests performed by the system merely check whether a file was successfully produced when running the report with some automatically chosen parameter values. Success does not necessarily mean that the report is behaving exactly as the author of the report intended it to, as the system does not inspect the content of the generated report file.

It is of course recommended that manual tests are performed to ensure custom reports produce the desired output. However, the provided auto-test functionality can be very useful to catch those errors which entirely prevent the running of a report.

Reports can be enabled and disabled using the context menu beside each report. A disabled report cannot be viewed or run by any user who is not a manager of the report. This provides a handy mechanism by which to temporarily remove access to a report, for whatever reason, while retaining all other settings for the report.

All newly-registered custom reports are created in the disabled state, requiring a manager to proactively enable the report before it becomes available to those users with the configured viewing permissions.

The large "plus" button at the top-right of the Reporting Hub allows you to create a new report. After choosing your report type, the system will take you through some basic questions relating to its initial configuration, such as asking you for the report's name and description.

In the case of a formatted report, one of the questions will ask you to identify which underlying SSRS report the new report registration should use. Formatted reports in Elements are implemented using reports hosted and rendered by SQL Server Reporting Services. Once the underlying SSRS report has been designed, and then deployed to SSRS in the proper place, it can be selected when registering a new formatted Report in the Reporting Hub.

Please see the following article for more information relating to the creation and registration of SSRS reports:

• How to set up and create custom SSRS reports in Elements

Unlike formatted reports, the entire definition of a dashboard or a data extract is stored within Elements itself. Elements is therefore in a position to offer the ability to fully copy these types of report using a single click. You will find a Copy entry in the context menu for this purpose. You can even copy stock dashboards and data extracts.

This represents a convenient way to get started with your own custom dashboards and data extracts, and is fully encouraged.

To copy a formatted report, one must first manually create a copy within SSRS itself, then create a new appropriately-configured formatted report registration in Elements which references the copied SSRS report.

Creating a new report, or clicking on the name of any existing report in the Reporting Hub, will redirect you to the details page for the report where several additional management options are available. Please see below.

The running of reports is secured using a two-step process.

Firstly, a report must be shared by a Reporting Hub Administrator with end-users using viewing permissions. Viewing permissions specify which users and groups are permitted to know of the existence of a report,  see that report listed in the Reporting Hub, and attempt to run it.

A user with viewing permissions can see the title and description of the report, and any other descriptive information not maintained specifically for managers only.

When attempting to run a report, the viewing user may require further permissions relating to any data they select when running it.

Some reports, such as group reports, are configured with parameters (see the section below). These represent questions to ask the user running the report when it is run.

For example, a group report, by definition, has a group parameter. When a user runs the group report, the report will ask the user to select from amongst the preconfigured set of groups supported by that parameter. However, only those groups on which the user also has suitable data usage rights will be offered.

Some reports are parameterless. This is the case for all dashboards and some formatted reports and data extracts. Parameterless reports do not require any rights checks to run beyond the viewing permissions discussed above.

Please see the subsections below for details of the particular permissions required for the various parameter types supported in the Reporting Hub

Note: Additional corresponding parameter types will be introduced to the Reporting Hub for use by Open Access waiver request reports, and the various UK REF-related reports are migrated into the Reporting Hub in future releases.

By definition, a report with a group parameter is known as a group report. A user who runs a group report is required to have statistician access on a group in order to select it when running the report.

The following roles convey this permission on all groups in the system: System Administrator, System Verifier, Reporting Hub Administrator, and Reporting Hub Super-Viewer. The following roles convey the permission on individual groups: Research Manager and Statistician.

Group reports automatically further restrict the viewing permissions above to prevent any user without this permission on at least one group in the system from even viewing the report.

A report with a user parameter is known as a user report. All users have permission over their own data, so will be able run a user report against themselves.

Some roles allow user impersonation, granting permission over the impersonated user’s data (e.g. Research Managers). When running a user report it is possible to search from a list of all available users and specify a user to run the report against.

Reports with a linked ‘groups’ and ‘users’ parameter allow the selection of multiple groups and/or users. Because these reports have a group parameter the reports automatically restrict the viewing permissions above to prevent any user without this permission on at least one group in the system from even viewing the report.

The ‘users’ parameter allows the selection of multiple users from the set of users that the person running the report has permission over (e.g. Research Managers for a group have permission over the data of all users in that group). 

A menu entry exists to support the deletion of a report in Elements. In the case of a dashboard or data extract, this is enough to delete all aspects of the report. However, the deletion of a formatted report leaves behind its report definition in SSRS. This must be manually deleted from SSRS if you wish to remove it from there also.

The parameters of a report represent the questions asked of a user who runs it, and their supported answers.

The above example shows three parameters. The first parameter represents a group. The set of available groups that can be chosen by the user when running the report can be configured using the clickable pencil "edit" button in the parameter's Availability section. Note that the actual list presented to the user will be the intersection of those defined here and the groups on which the user has the required data rights. See the Report Viewing and Running Permissions section above.

The other two parameters will result in Elements asking the user the report to provide a date range: a start date and an end date. These parameters can be removed by unchecking the "Enable date range" checkbox. However, you must manually ensure that the corresponding SSRS date parameters are removed from any underlying SSRS report definition if you do this.

In fact, the listed parameters must at all times be maintained in one-to-one correspondence, by name and data type, with the list of parameters configured in SSRS for the underlying report itself. Otherwise, errors will be experienced when attempting to run the report.

It may be of use to maintain a set of notes about a report for the eyes of Reporting Hub Administrator only. This could be for any reason, such as recording information about how the report works for future maintainers, any plans for future development, etc. or any relevant information about the sensitivity of the information surfaced by the report.

Some events of interest relating to the report are recorded and displayed down the right-hand side of the page. These include the moment of report creation, as well as whenever the report is enabled or disabled, has its descriptive metadata modified or its definition/behaviour modified.

The moment of creation of a report is ordinarily defined as the time at which it was registered in the Reporting Hub. This avoids certain potential complexities in favour of simplicity and clarity.

For example, a formatted report recently registered in the Reporting Hub might correspond to an SSRS report created a long time ago in SSRS. The creation date shown reflects the time of registration in the Reporting Hub.

Where legacy reports are migrated into the Reporting Hub during an Elements version upgrade, Elements preserves any previously recorded creation date for that report. Where such a date has not been recorded by legacy functionality (e.g. for group reports), the upgrade records the date of creation of the report as the date of migration into the Hub (i.e. the date of upgrade).