In-App vs. Data Warehouse Reports

Owned by Holly Mistlebauer
Last updated: Feb 14, 2019
4 min read

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.

History

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 Resource Access SIG, Resource Management SIG, User Management SIG, and Metadata Management SIG are what we call the “functional area” SIGs.  These SIGs all began operation before the Reporting SIG, with the Resource Management SIG leading the way. As each SIG began defining the features for their area, the shared need for some reports arose.  For example, the Resource Access SIG identified the need for a report that lists the patrons who are due fee/fine refunds. Given the complexity of refunding fees/fines via the various payment methods in use, it was decided by the SIG that the easiest approach for now is to simply create a report that will be used by the library to issue refunds in the manner they choose.  This report is needed by the workflow, so it has been labelled a “workflow report”--fee/fine refunds as defined will not work without this report. The SIG also agreed that it was necessary to have a report that listed all fees/fines that were cancelled as errors. If a lot of fees/fines are being cancelled as errors, perhaps there is something wrong with how the automated fees/fines are being billed?  This type of report has been labelled a “log/audit report”--it isn’t need by the workflow, but it is a great management tool.

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:

  1. 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)
  2. Established criteria for in-app reports (information provided below)
  3. Had all product owners review the Reporting SIG Master Spreadsheet to -
    1. Identify which reports they were already working as in-app reports (see “In-App Report?” column of spreadsheet)
    2. Identify which reports could be folded in as in-app reports (see “In-App Report?” column of spreadsheet)
  4. Had all product owners add in-app reports to the UXPROD JIRA project as features
  5. 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

In-app reports usually* meet all of the following criteria:

  1. They are needed by all institutions, not just one or two (the PO/SIG should not be spending time designing a report for one or two institutions)
  2. They use data from one application (e.g. User)
  3. They are needed daily or weekly (as part of the workflow)
  4. They deliver real-time data

*not saying must because there are always exceptions (for example, an institution implementing before the data warehouse is available may need some reports created for them that other institutions don't need)

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

Any report that is not a in-app report is a data warehouse report--we only have these two types of reports.  Data warehouse reports are usually monthly or yearly statistical reports that are required by one or two institutions, but they are not limited to that.

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.