Overview
The purpose of this document is to give a history of the split between in-app and data warehouse reports and attempt to define the difference going forward. This document does not cover exported .csv files, which could be viewed as another type of report.
...
When the Reporting SIG began operation, one of its first tasks was to compile a list of reports that were needed by the various participating institutions. The end result is what we call the Reporting SIG Master Spreadsheet. This is a working document that continues to be added to and updated. The “reports” listed are a mixture of daily, weekly, monthly, yearly, and on-request reports and extracts. Many of the reports are similar across one or several institutions, but just as many are unique to one institution. The Reporting SIG has been working to consolidate the reports as much as possible.
...
The need for the Reporting SIG and functional area SIGs to work together quickly became clear--we didn’t want the same reports to be worked on by both the Reporting SIG and the functional area SIG. It made sense for the product owners to work with the subject matter experts on the SIGs to define these “in-app” reports, while the business analysts on the Reporting SIG focused on the statistical reports that would come from the data warehouse. Sharon Beltaine (the Reporting SIG convener) and Holly Mistlebauer (one of the Resource Access SIG product owners) worked together to plan how this would work. The FOLIO project took the following actions:
- Agreed that the Reporting SIG Master Spreadsheet would be the report list for ALL FOLIO reports (which also led to the Consortial SIG adding their reports to spreadsheet)
- Established criteria for in-app reports (information provided below)
- Had all product owners review the Reporting SIG Master Spreadsheet to -
- Identify which reports they were already working as in-app reports (see “In-App Report?” column of spreadsheet)
- Identify which reports could be folded in as in-app reports (see “In-App Report?” column of spreadsheet)
- Had all product owners add in-app reports to the UXPROD JIRA project as features
- Added an “in-app_reports” tab to the Reporting SIG Master Spreadsheet where the product owners provided information about the in-app reports, including the JIRA links
Any report that is not identified as an “in-app report” is considered to be a “data warehouse report.” The data warehouse reports each have a JIRA issue in the Reporting JIRA project.
Identifying In-App Reports
...
Within JIRA, in-app reports are located in the UX PRODUCT project (the JIRA Issue Key begins with UXPROD-) and have the label appreport. See the full list of in-app report JIRA issues here.
Identifying Data Warehouse Reports
...
Within JIRA, data warehouse reports are located in the REPORTING project (the JIRA Issue Key begins with REP-) and have the label dwreport. See the full list of data warehouse report JIRA issues here.
Why can't all reports be Data Warehouse Reports?
All reports cannot be data warehouse reports because some are part of a FOLIO workflow. For example, when refunding fees/fines the Resource Access SIG decided not to automated the process of actually making the payment to the patron. Instead, they want a report that lists the patrons who are owned refunds, with the amount owed, and the institution will have refunds issued by whatever office at their institution does refunds using whatever method they use. Producing this list is part of the refund fees/fines workflow. If this is moved to the data warehouse we are in effect saying that to use FOLIO fees/fines refund functionality you have to have a data warehouse. That is not logical.