# | Release | Impact Name | Description | Priority | Impact Type | Affected Groups | Related Jiras | Imp Team | Development Needed | Current Status | Recommended Approach |
---|---|---|---|---|---|---|---|---|---|---|---|
1 | Data Collision Avoidance Mechanism | Data collision happens when a record is acted on simultaneously by two agents (batch load and/or human for example) causing the record to not include both sets of updated data. These issues can also happen when the changes are unknowingly sequential instead of simultaneous. This can happen when 2 batch updates are in conflict, when a batch update happens while a staff member edits a record, or when 2 staff members attempt to edit the same record at the same time. The user should be notified when the a record they are about to save has been updated since the time that they opened the record. --capacity limit, productivity loss, data Integrity/loss | 01 – Extreme | Quality | all staff patrons | MM | |||||
2 | Bulk edit records | Much of our current efficiencies are hinged on the ability to change many records at one, to bulk edit or make global changes. Processes like these have meant that the reduction on staffing levels has been possible without too much negative consequences to our services to patrons. Lack of bulk edits impacts DUL heavily partly due to staffing decisions and levels. Impact is cross-function and cross-app. In-depth analyses for the use-cases of bulk edits, as well as potential work-a-rounds are listed on this MMSIG page. --productivity loss, data integrity/loss, capacity limit, functionality | 02 – Extreme | Capability | all staff patrons | UXPROD-120 UXPROD-2370 | MM | ||||
3 | Data Import Infrastructure | Data import hinges on the ability to extend metadata from one data source into another, and on the ability to troubleshoot loads that cause errors in real time. Additionally, the ability to roll-back a record load if errors are discovered during data import is not possible. The ability to have "MARC to MARC" match routines which allows imported records to overlay based on locally set criteria is imperative for our data-flows. We rely on vendor record numbers which may not be held in the MARC 035, for example. --data integrity/loss, productivity loss | 03 – Extreme | Quality | technical services LSIS patrons | MM | |||||
4 | Record Deletion | We cannot delete bibliographic or holdings records from FOLIO either in batch or individually. Having extraneous data can adversely impact the performance of the system and cause confusion to staff. Record deletion from Inventory and the SRS is a necessary part of maintaining efficient workflows and data integrity. --productivity loss, data integrity/loss, reporting | 04 – Extreme | Quality | technical services LSIS | UXPROD-1624 | MM | ||||
5 | MARC holdings structure and storage | Staying in compliance with the ANSI/NISO standards for holdings data is crucial to the stability of data management. In order to avoid deprecation of rich holdings data in FOLIO and future systems, maintaining use of this industry standard is needed. Data loss and deprecated services to patrons is the danger in implemented the FOLIO holdings format. Ability to import, store, edit, view, create MARC holdings records, and link those underlying SRS records to Inventory holdings records so that the source of truth is the MARC record in SRS. --productivity loss, data integrity/loss | 05 – Extreme | Capability | all staff patrons | MM | |||||
6 | Profile improvements for data export jobs | Staff need to be able to trust that the working profiles are correct. Out-of-date job profiles could result in sending inaccurate data to vendors (i.e.: authority control vendor systems), work-a-rounds that include export, edit in a 3rd-party system, and re-import could cause data loss, and loss of data integrity, exporting data for Books & Media, Summon discovery, WorldCat and RapidILL could be compromised. IPEDS, ARL, and local statistics in use for planning and trend analysis are also fragile based on this gap. Based on some criteria (order info, invoice data, bib data, etc.) export a set of MARC records (BiB, HOL, AUTH) as a .mrc file. --data integrity/loss, productivity loss, budget implications | 06 – Extreme | Quality | all staff patrons | UXPROD-2453 | MM | ||||
7 | Export Inventory data in delimited file format | Staff regularly export data in delimited files (i.e.: csv=excel) for reporting purposes, or as the base for running other batch processes, or for manual clean up projects. Requires ability to export certain elements from across the various functional areas, not entire MARC records, Order records, etc., but elements of those records. --productivity loss, reporting | 07 – Extreme | Capability | technical services assessment & user experience collection strategy & development | MM | |||||
8 | Bulk moving holdings/items between holdings | Staff routinely move holdings records and their associated items from one bib record to another in batch as well as manually, especially for serials maintenance, but also for error clean-up. Items are moved between holdings records on an almost daily basis as materials are moved (i.e.: to the LSC). Being able to update these relationships in bulk is a key piece of functionality. If there is a delay in knowing where materials are, then our service to patrons will be limited. Lack of bulk moving records impacts DUL heavily partly due to staffing decisions and levels. Impact is cross-function and cross-app. --productivity loss, data integrity/loss, reporting | 08 – Extreme | Capability | all staff patrons | MM | |||||
9 | Morning Glory | Bound-With Relationships in the UI | Currently, we have hundreds of thousands of materials that are bound together with other titles, creating a "bound-with" item record. These are difficult to manage in our system, but are much less so in FOLIO. Some bound-with features have been developed by the only way to create or maintain bound-with item data in FOLIO is through API. This means that creating, editing, or deleting bound-with data is not possible in FOLIO. Even viewing bound-with relationships is not possible until the UI is developed. --productivity loss, data integrity/loss | 09 – Extreme | Quality | all staff patrons | MM | ||||
10 | Print/Save records external industry software | Compiled list of printing use-cases, save to PDF included in issue. | Minor | Capability | staff | UXPROD-2974 | MM | ||||
11 | Single Record Import | OCLC push/pull limitations – needs fuller description | Moderate | Capability | technical services | MM | |||||
12 | Mark a Record for Deletion | Mark for deletion is the method in use to prevent some staff from accidentally deleting needed instance records. Marking for deletion would allow for assessment of marked records' associated data prior to batch deletion. There is no reliable, sustainable work-around in FOLIO to accomplish this workflow. --productivity loss, data integrity/loss, reporting | Moderate | Capability | technical services LSIS | MM | |||||
13 | Recording Productivity Stats | To be able to keep productivity statistics in place of the CID field in Aleph which allows us to track production statistics, evaluate processing queues, and is used in troubleshooting. --reporting, productivity loss | Moderate | Cost | technical services | UXPROD-2867 | MM | ||||
14 | Multiple graphical representations in FOLIO, e.g. resource titles in Inventory | Any FOLIO property (title, author, subject, etc.) can be represented in more than one script. All scripts are graphical representations of their related language. The inability to display or search by these elements in the vernacular, original script impairs efficient processes. --functionality, productivity loss | Significant | Quality | technical services access and delivery services | UXPROD-1646 | MM | ||||
15 | Maintain relationships among Instance records and Acquisitions records | The ability to maintain relationships between data among apps when holdings/items are moved from one instance to another, or when data is updated, is paramount to efficient workflows and data integrity. Dynamic links between apps are present, but break when data is updated (i.e.: titles are changed through record overlay). Staff should only be able to intentionally break relationships between record types. --data integrity/loss | Significant | Quality | technical services access and delivery services patrons | UXPROD-1647 | MM | ||||
16 | Inventory Search and Filter Enhancements | Numerous enhancements to searching and filtering are needed in Inventory. Elastic Search, if implemented, may solve many of those problems. Many search-related JIRAs are paused while we await the development of Elastic Search. For example, search results show an estimated number of results, not an exact count. This makes processing batch changes more fragile. --productivity loss | Significant | Capability | technical services access and delivery services | UXPROD-2712 | MM | ||||
17 | Keyboard commands for navigation and editing | There is an overall lack of keyboard commands in FOLIO, meaning everything has to be done with mouse clicks for menu and record navigation. Additionally, the lack of these prevent sophisticated macro development in third party systems such as MacroExpress. Additionally, built-macros to create new fields or records (i.e.: the F-keys) do not exist in FOLIO. --ergonomic injury, productivity loss, data integrity/loss | Significant | Cost | all staff working in FOLIO apps | UXPROD-2891 | MM | ||||
18 | Improve functionality of display of results for Inventory searches | This includes numerous improvements to the navigation experience in FOLIO which right now is very confusing because it is not very intuitive. For example, currently, you cannot search by item data (like barcode) and be taken directly to the correct item, which is something of an industry standard. Likewise, you cannot search for holdings data and be taken directly to the specific holdings record. --productivity loss | Significant | Capability | technical services access and delivery services | UXPROD-491 | MM | ||||
19 | Freezing a Patron Record | Freezing is the ability to freeze part or all of a patron record to prevent the nightly patron load from overriding values on the record. FOLIO does not have this feature. Impact: Unable to support honors undergraduates having extended loan periods for DUL materials. Unable to disable email delivery to patrons who have recently passed away. Unable to disable service for patrons receiving inappropriate access (e.g., students who graduate but have non-terminated staff positions.) Unable to temporarily offer a different loan period to patrons who might need it (e.g., delivery b/c of temporary mobility issues.) | Significant | Capability | Faculty Staff Students | UXPROD-242 | RA | Yes | No change; jiras not scheduled | ||
20 | Notices come from single address | All notices will come from a single address (meaning patron replies will go to a single address.) Impact: In Aleph, notices came from the associated library. Having to coordinate a single mailbox will slow down response time to patron queries and increase general overhead for staff. | Significant | Capability | Library staff Faculty Staff Students | UXPROD-2156 | RA | Yes | No change; jiras not scheduled | ||
21 | Optimistic Locking in Users | Optimistic Locking is FOLIO's first pass at providing record integrity support for multiple users accessing a single record and preventing data being written over / corrupted. Optimistic Locking is scheduled for basic implementation in Kiwi for the Inventory app, but is not yet scheduled for Users. Impact: It is a not-infrequent occurrence for two resource access staff to open the same user record at the same time. Aleph prevents the second user from opening the record - FOLIO will not. No workaround is available | Moderate | Quality | Library staff Data | UXPROD-3534 | RA | Yes | No change; jiras not scheduled | ||
22 | Barcodes with spaces | We have thousands of records that have spaces at the end of the barcode. With our Juniper upgrade, our barcodes were loaded with no space at the end. This means that a checkout succeeds, but an inventory search with the barcode scan fails, until you take the space off the end of the barcode. More to come on determining path/impact. | TBD | TBD | TBD | RA | |||||
23 | No ability to identify items/group combos that are eligible for Scan and Deliver service | Currently, we implement Scan and Deliver (basically a version of document delivery) in the CRS. Eligibility for scan and deliver depends on patron group and item information and is generated as part of the circ rules using Aleph's photocopy settings. FOLIO does not have a similar area of settings that we could easily identify to enable this as part of circulation rules. If we need to continue Scan and Deliver, it will need to be built as part of the requirements for the new catalog request system, and we will need to decide how those items will be identified. | Significant | Capability | Faculty Students | N/A | RA | N/A | |||
24 | Inability to restrict pickup locations or delivery options by material type, loan type, patron type or item location | When a patron places a successful request for an item, they will be able to ask to have it delivered to any pickup location in FOLIO. E.g., we will not be able to say that grad students can page items from Music but only for delivery to non-Music locations. Or, we won't be able to allow delivery of items from the LSC to campus but only to the library that sent it to the LSC in the first place.
Related to this is https://issues.folio.org/browse/UXPROD-2649 - overriding requests that were blocked by policy. That one is an R1 and is also not scheduled. If that doesn't make it, there will be no way in FOLIO for staff to be able to request an item that the patron was prohibited from requesting. One approach to the inability to override requests could be creating users that staff use to request these items on behalf of, and then using a special patron group to ensure that those match. | Significant | Capability | Library staff Faculty Staff Students | RA | Yes | no progress; jiras still not scheduled | |||
25 | Check-in and Check-out performance | The first institution with comparable circulation activity to Duke - Cornell - has reported check-in and check out performance of 1 to 5 seconds per transaction. The project has been targeting 1 second as the max per transaction, and this is real-life performance testing that is showing that with large record sets it is not getting there. Impact: Performance of the system will be a huge signifier to staff as to whether our move to FOLIO will improve service. 1 to 5 seconds per check-in or check out transaction will significantly slow down our service delivery | Significant | Capability | Library staff Faculty Staff Students | UICHKOUT-726 UICHKIN-269 | RA | jiras remain open; comments and convo with cornell suggest work has happened, but unclear as to how that is being documented or contributed back to community chicago's performance so far seems promising (they went live MLK weekend). | |||
26 | Supporting DKU (multiple tenant level locales) | Right now, FOLIO has one tenant-level locale which means that everything runs in one time zone. For DKU, that means that notices, UI display, and other timezone features will not reflect their time in China. Impact: There would be significant confusion in the UI for DKU library staff that would likely impact their ability to deliver good service. | Extreme | Capability | Library staff Faculty Staff Students | UXPROD-592 | RA | Yes | no progress; Jira not scheduled | ||
27 | Inability to control requesting behavior for various item states Impact Analysis - Inability to control requesting behavior for various item states | To get the first round of requesting live for Chalmers, the RA SIG agreed to hard code behavior for requesting around specific item states. (That is documented in the FOLIO community wiki here - https://wiki.folio.org/display/FOLIOtips/Request+Type+Whitelist+Matrix - see "Whitelist.") There is a feature to add the ability to configure these settings independently but it has not been developed. Impact: The agreed-upon whitelist allows patrons to place requests on missing items. This would be a significant departure from our general approach to customer service and we'd need to invest development time in figuring out how to work around it / redirect eligible patrons to interlibrary request. | Moderate | Capability | Faculty Staff Students | UXPROD-1320 | RA | Yes | no progress; Jira not scheduled | ||
28 | Aged to lost notices do not send in bulk | Aged to lost fee/fine notices send one per item, rather than a bulk send all at once. Impact: if we used the current implementation, we would send one email per each fee/fine. An average lost item has a lost fine and a handling fee. That means that if a patron let ten books age to lost, they would receive twenty separate emails. There is a workaround, but we will have to use a less-featured type of email that will provide us with fewer customization options. | Moderate | Capability | Library staff | UXPROD-2252 | RA | Yes | has moved to "in refinement" | ||
29 | Lack of item status history in the UI | Resource Access staff frequently need to track down items that are not where they are expected to be. A key tool is being able to view an item's history - to see when it was last "touched", when it last circulated, where it may have been requested. FOLIO's circulation log app has some features that support this, but a major missing feature is the ability to track transitions in an item state - for example, to see that an item was requested, but then declared missing a week later. Impact: There are no workarounds for the lack of this feature. We will likely see a slowdown in staff productivity, and loss of some library materials because they cannot be found when they go missing. | Significant | Quality | Library staff | UXPROD-2175 | RA | no progress, not scheduled | |||
30 | No support for a reshelving item state (FOLIO plans to call it Recently Returned). | This item status does not exist in FOLIO, so Items that are returned will go immediately to 'available'. Not all libraries use this status, but DUL does. Impact: Without this feature, patrons will go to the shelf expecting an "available" item that may have just been returned an hour before. Patrons will experience confusion and frustration not finding an item on the shelf that they expected to be there. There is no workaround. | Moderate | Capability | Library staff Faculty Staff Students | RA | Yes | no progress, not scheduled | |||
31 | Lack of "Arrived" status for items | When an item is received in FOLIO, it gets a status of "In Process." If other workflows also use that status, it will be difficult for staff to know if an item has arrived / is possibly at Tech Services. Impact: Staff frequently use the Arrived status in FOLIO to troubleshoot item delivery and provide information to patrons about the status of ordered items. There is a workaround for this, but it will be time consuming for staff. | Minor | Capability | Library staff | There are a number of open jiras that touch on item state. A few select ones: | RA | No | no progress, not scheduled | ||
32 | Unable to delete or cancel a loan | There is no ability to delete or cancel a loan through the FOLIO UI. If a loan is generated unintentionally, either by a staff member or an automated process, the loan will have to be discharged to get it to clear. This may lead to data integrity and reporting issues. May also be an issue with LSC and returning items that have been hanging around "In transit." | Moderate | Quality | Library staff Data | UXPROD-90 | RA | no progress, not scheduled | |||
33 | Anonymizing loans | FOLIO anonymizing features are incompletely implemented. Custom fields (where we are keeping demographic information) are not retained on anonymization, nor is the user department field. If we choose to do across the board anonymization, we would lose important reporting data. Impact: We have decided not to anonymize until our needed features are built. Anonymization on demand for a single user will be available, but decisions will need to be made about how to advertise that service and how to assess potential impact on reporting data. | Negligible | n/a | Faculty Staff Students Data | RA | Yes | no progress, not scheduled | |||
34 | Batch Renewals | We will have no automatic renewal functionality. Theodore Tolstoy from EBSCO has a python script that can be used to edit due dates for open loans - https://github.com/FOLIO-FSE/FOLIO-backup-and-restore/blob/master/service_requests_tools/extend_open_loans.py - cludgy but possible to leverage for this. Chicago also has tools they are using for this. | Minor | Capability | Faculty | UXPROD-2375 | RA | ||||
35 | Issues with Faculty Delivery | The impact here is not that faculty delivery doesn't work in FOLIO, since we do it by hand right now in Aleph. The issue is that there is no way for us to hide the Awaiting Delivery functionality that will be visible in various apps, and we will need to teach people not to use it until it is working as expected. | Negligible | n/a | Library staff | RA | Analysis Complete; no release scheduled | ||||
36 | No shortcut key to clear a checkout session | This is something staff have relied on to protect patron information. It will be a training issue that we will have with staff. There is a timeout option for check-out (Settings > Circulation) and we can investigate having it timeout. | Negligible | n/a | Library staff | UICHKOUT-683 | RA | ||||
37 | No permission control over backdating returns | Backdating returns has traditionally been something we have kept tight control over because it has the potential to result in mischief (or have friends pressure their friends who work at the library to help them avoid a fine.) This is very unlikely to be developed anytime soon and backdating is also not in the circulation log. | Moderate | Capability | Library staff | RA | Yes | ||||
38 | No offline support | FOLIO has no defined support for offline transactions. Aleph does have support for offline transactions, though it is very tricky and easy to mess up, so not all libraries use it consistently. We will want to define a CAST-wide workflow and policies for how we do checkouts if FOLIO is offline. | Negligible | n/a | Library staff | UXPROD-1275 | RA | ||||
39 | Inability to easily print check-in receipts | FOLIO does not handle "print screen" well at all and there are no built-in features to support printing ad-hoc check-in receipts. Aleph doesn't handle this very well either; this will be a training issue. The best option will be to screenshot the check-in screen and print the screenshot. | Negligible | n/a | Library staff Faculty Staff Students | RA | |||||
40 | Creating requests for Rush orders | RM Impact Analysis - see line 11 - FOLIO does not support an automatic workflow to create a patron request for a rush order like Aleph does - this needs further discussion to understand how we want workflows to happen in FOLIO | Moderate | Capability | Faculty Staff Students | RA | |||||
41 | Item has been received and is being processed for Collection Spotlight | IPS: AP Resource Access staff make heavy use of a variety of item process status values to enable tracking of items as they move through the library, and to provide correct information on an item to the catalog request system (e.g., to disable requesting if an item is not on the shelf.) FOLIO's original design assumed a three-part item state field that was meant to provide extensive flexibility for supporting item tracking workflows. Only one of the three pieces has been developed - availability - and the current list of item statuses for availability does not adequately match our use cases. Impact: There are workarounds that can be defined in these cases but they are time-intensive, will impact staff productivity in all departments (not just Resource Access,) and will increase the amount of time that materials are not available for patrons. | Minor | Capability | Library staff | There are a number of open jiras that touch on item state. A few select ones: UXPROD-2606 | RA | no progress, not scheduled | |||
42 | Item is being worked on in Collection Development | IPS - CD Resource Access staff make heavy use of a variety of item process status values to enable tracking of items as they move through the library, and to provide correct information on an item to the catalog request system (e.g., to disable requesting if an item is not on the shelf.) FOLIO's original design assumed a three-part item state field that was meant to provide extensive flexibility for supporting item tracking workflows. Only one of the three pieces has been developed - availability - and the current list of item statuses for availability does not adequately match our use cases. Impact: There are workarounds that can be defined in these cases but they are time-intensive, will impact staff productivity in all departments (not just Resource Access,) and will increase the amount of time that materials are not available for patrons. | Minor | Capability | Library staff | There are a number of open jiras that touch on item state. A few select ones: | RA | no progress, not scheduled | |||
43 | Sending an item to Conservation for Repair | IPS - CD Resource Access staff make heavy use of a variety of item process status values to enable tracking of items as they move through the library, and to provide correct information on an item to the catalog request system (e.g., to disable requesting if an item is not on the shelf.) FOLIO's original design assumed a three-part item state field that was meant to provide extensive flexibility for supporting item tracking workflows. Only one of the three pieces has been developed - availability - and the current list of item statuses for availability does not adequately match our use cases. Impact: There are workarounds that can be defined in these cases but they are time-intensive, will impact staff productivity in all departments (not just Resource Access,) and will increase the amount of time that materials are not available for patrons. | Minor | Capability | Library staff | There are a number of open jiras that touch on item state. A few select ones: | RA | no progress, not scheduled | |||
44 | Mark an item as In Route | IPS: RO Resource Access staff make heavy use of a variety of item process status values to enable tracking of items as they move through the library, and to provide correct information on an item to the catalog request system (e.g., to disable requesting if an item is not on the shelf.) FOLIO's original design assumed a three-part item state field that was meant to provide extensive flexibility for supporting item tracking workflows. Only one of the three pieces has been developed - availability - and the current list of item statuses for availability does not adequately match our use cases. Impact: There are workarounds that can be defined in these cases but they are time-intensive, will impact staff productivity in all departments (not just Resource Access,) and will increase the amount of time that materials are not available for patrons. | Minor | Capability | Library staff | There are a number of open jiras that touch on item state. A few select ones: | RA | no progress, not scheduled | |||
45 | Send an item for scanning in Collection Development on the Scribe | IPS: Resource Access staff make heavy use of a variety of item process status values to enable tracking of items as they move through the library, and to provide correct information on an item to the catalog request system (e.g., to disable requesting if an item is not on the shelf.) FOLIO's original design assumed a three-part item state field that was meant to provide extensive flexibility for supporting item tracking workflows. Only one of the three pieces has been developed - availability - and the current list of item statuses for availability does not adequately match our use cases. Impact: There are workarounds that can be defined in these cases but they are time-intensive, will impact staff productivity in all departments (not just Resource Access,) and will increase the amount of time that materials are not available for patrons. | Minor | Capability | Library staff | There are a number of open jiras that touch on item state. A few select ones: | RA | no progress, not scheduled | |||
46 | Put an item on Exhibit | IPS: XB Resource Access staff make heavy use of a variety of item process status values to enable tracking of items as they move through the library, and to provide correct information on an item to the catalog request system (e.g., to disable requesting if an item is not on the shelf.) FOLIO's original design assumed a three-part item state field that was meant to provide extensive flexibility for supporting item tracking workflows. Only one of the three pieces has been developed - availability - and the current list of item statuses for availability does not adequately match our use cases. Impact: There are workarounds that can be defined in these cases but they are time-intensive, will impact staff productivity in all departments (not just Resource Access,) and will increase the amount of time that materials are not available for patrons. | Minor | Capability | Library staff | There are a number of open jiras that touch on item state. A few select ones: | RA | no progress, not scheduled | |||
47 | Send an item for binding | IPS: "CB - Commercial Bindery, OB - Out to Bindery, PB - Bindery-Boxing, RB - Ready to Bind, IB - In Process-Binding, BD - Sent to Binding" Resource Access staff make heavy use of a variety of item process status values to enable tracking of items as they move through the library, and to provide correct information on an item to the catalog request system (e.g., to disable requesting if an item is not on the shelf.) FOLIO's original design assumed a three-part item state field that was meant to provide extensive flexibility for supporting item tracking workflows. Only one of the three pieces has been developed - availability - and the current list of item statuses for availability does not adequately match our use cases. Impact: There are workarounds that can be defined in these cases but they are time-intensive, will impact staff productivity in all departments (not just Resource Access,) and will increase the amount of time that materials are not available for patrons. | Moderate | Capability | Library staff | There are a number of open jiras that touch on item state. A few select ones: | RA | no progress, not scheduled | |||
48 | Send an item to technical services | IPS: TS Resource Access staff make heavy use of a variety of item process status values to enable tracking of items as they move through the library, and to provide correct information on an item to the catalog request system (e.g., to disable requesting if an item is not on the shelf.) FOLIO's original design assumed a three-part item state field that was meant to provide extensive flexibility for supporting item tracking workflows. Only one of the three pieces has been developed - availability - and the current list of item statuses for availability does not adequately match our use cases. Impact: There are workarounds that can be defined in these cases but they are time-intensive, will impact staff productivity in all departments (not just Resource Access,) and will increase the amount of time that materials are not available for patrons. | Moderate | Capability | Library staff | There are a number of open jiras that touch on item state. A few select ones: | RA | ||||
49 | Nolana | Data import for MARC Invoice and MARC Order data | Lehigh developed a temporary solution that UChicago has expanded which we should investigate.
Impact Current acquisitions staffing levels rely on automated processes to load invoices and order data so that they do not have to be manually keyed. If we are unable to automate the import of MARC invoice and order data, Monograph Acquisitions staff will not be able to handle the current volume of ordering and invoicing that DUL does. If these functions are not automated, and we want to get all of our orders placed and invoices for them paid in the appropriate fiscal year, then we need to add more staff time. Alternatively, we could reduce the amount of ordering we do. Not paying invoices in a timely manner isn't an acceptable alternative. | Extreme | Capability | Library staff and patrons | RM | Yes | Expected in Nolana (R3 2022) | See Impact Analysis: Data import for MARC Orders and Invoices for more details about managing this gap. | |
50 | Automated receiving for data import invoices | Aleph automatically handles arriving materials as part of the MARC invoice loading. There isn't a distinct JIRA to describe this feature, so we need to make sure it's included in the development of MARC invoice import UXPROD-663. Dennis Bridges created a wiki page to describe requirements. Impact rely on automated processes to automatically arrive materials as part of the MARC invoice loading process. If this has to be done manually, and staffing levels and ordering volume stays the same, then we will develop backlogs of material waiting to be arrived. This means that it will take significantly longer for newly acquired materials to become available to patrons. Current acquisitions staffing levels | Significant | Cost | Library staff and patrons | UXPROD 3227 was created on 8/24/21. | RM | Yes | Not scheduled. | See Impact Analysis: Data import for MARC Orders and Invoices for more details about managing this gap. | |
51 | Serials check-in See Impact Analysis: Receiving | Lack of prediction patterns in FOLIO will require staff to enter information about each piece as they arrive rather than checking off arrivals from a system-generated list of expected pieces. Impact rely on automated processes to generate items for each issue of a periodical that arrives. If the current volume of periodical orders stays the same and staffing does not increase, then we will develop a backlog of periodicals issues waiting to be manually added to FOLIO. This means that it will take significantly longer for newly arrived materials to become available to patrons. Furthermore, the manual creation of all data for every single new issue greatly increases the risk of inaccurate data being introduced into the system, thus reducing the discoverability and accessibility of these materials to patrons. Current acquisitions staffing levels | Significant | Cost and Quality | Library staff and patrons | RM | Yes | Not scheduled | See Impact Analysis: Receiving for more info about managing this gap. Not scheduled | ||
52 | Claiming ordered materials that are missing See Impact Analysis: Receiving | FOLIO currently doesn't offer any reports to identify which expected pieces are missing. Impact Missing materials won't be claimed promptly from vendors which means we've paid for materials we haven't received. Patrons looking for ongoing print materials may not find what they need. As our print serial collections become more and more focused on areas of special focus, the ability to identify and claim materials that may not have arrived is even more essential, not only to make sure we are getting what we paid for, but to ensure that these serials are preserved for posterity. | Significant | Cost and Quality | Library staff and patrons | Not scheduled | RM | Yes | Not Scheduled | See Impact Analysis: Receiving for more info about managing this gap. | |
53 | Historical Order Information | Will FOLIO be capable of storing all historical order data from Aleph? Impact it will take longer to resolve issues. For e-resources especially, access to historical order information is critical when researching disputes with vendors about access - often the order is needed to prove to a vendor that we should have access to something we ordered many years ago. Staff can currently search all orders from within one system. If they have to search in two places (for example, the LDP for older closed orders and FOLIO for newer orders) | Significant for e-resources/special collections; Moderate for others | Cost | Library staff and patrons | n/a | RM | Maybe | See Impact Analysis: Historical Orders for more information about managing this gap. | ||
54 | Nolana | Secure file transfer for invoice feed to AP | FOLIO doesn't currently support SFTP or SCP secure channel file transfer for the export file of vouchers. Uses just FTP currently from Settings > Invoices > Batch configuration. Watching UXPROD-2843 to implement SFTP. | Recommend refer to business services | Recommend refer to business services | Data | UXPROD-2843 | RM | Expected in Nolana release. | ||
55 | Validation of invoice feed to AP | FOLIO doesn't offer any "preview" reports (as Aleph does) of which invoices will be included in a batch export. The process to validate which invoices are going to AP and to balance the amounts against the submitted paper invoices may be more difficult and time-consuming for staff especially if issues need to be tracked down and resolved. Impact DUL Business Services staff and staff at each professional school library who manage invoice feed to AP. payment errors will occur which would require significant staff time to untangle. DUL Business Services verifies that the totals being sent to AP balance with the totals on the paper invoices submitted for the batch being run prior to sending the data to AP. This ensures that any errors are corrected within the library system prior to sending the payment info to AP. If the batch is sent without this analysis step, | Significant for e-resources since lack of payment can mean loss of access Moderate for physical collections | Cost | Library staff and patrons | n/a | RM | Yes | Waiting for specification of requirements for custom reporting from LDP. | Local development: Build solution using LDP. | |
56 | User-specific defaults for order and item creation | FOLIO lacks the ability to save order and item creation defaults at the user level. Order templates are available in FOLIO but are shared across all users. Impact Backlogs of orders, invoices, and materials will develop, and patrons will experience delays in having access to newly acquired materials. hen considered with other impacts on this list, what seem like minor inconveniences in using the system are likely to result in a significant increase in the amount of time it takes acquisitions staff to do their work.This lack of functionality alone could result in order records taking 2-3 times longer to create in FOLIO than in Aleph. At scale, this could significantly impact the efficiency with which the current number of staff can do their work, both in terms of placing orders on behalf of subject librarians and receiving incoming material. | Significant | Cost and quality | Library staff | RM | not scheduled | Unfortunately, this functionality will not be available at Go-Live. | |||
57 | Record locking | Lack of record locking in Orders, Invoices, Finance and Receiving. FOLIO doesn't prevent two users from editing the same record simultaneously. Aleph prevents the second user from opening the record. Optimistic Locking would manage multiple users accessing the same record and prevent data from being overwritten or corrupted. Scheduled for basic implementation in Kiwi for the Inventory app, but is not yet scheduled for other apps yet. JIRAs only exist for Orders and Organizations as of 6/21/21. Julie added a request for this topic to be discussed at a future Acquisitions SIG meeting. Impact Data loss/corruption could occur. This could impact financial records, orders, invoices. If errors occur and need to be investigated and fixed that will cost staff time to untangle. | Significant | Quality and Capability | Data | (umbrella across all apps) | RM | not scheduled | |||
58 | Order material type shared with item material type |
Impact When considered with other impacts on this list, what seem like minor inconveniences in using the system are likely to result in a significant increase in the amount of time it takes acquisitions staff to do their work. Backlogs of orders, invoices, and materials will develop, and patrons will experience delays in having access to newly acquired materials. | Moderate | Cost | Library staff | RM | Yes | Candidate for local development or with GBV/HBZ not scheduled | Local or collaborative development: Add new data element to the orders app. | ||
59 | Patron holds for rush orders | FOLIO doesn't support automated requesting from the purchase order, so until UXPROD-2565 is implemented, acquisitions staff will need to do several more steps:
Impact When considered with other impacts on this list, what seem like minor inconveniences in using the system are likely to result in a significant increase in the amount of time it takes acquisitions staff to do their work. Backlogs of orders, invoices, and materials will develop, and patrons will experience delays in having access to newly acquired materials. | Moderate | Cost | Library staff | RM | not scheduled (tagged as "morning glory candidate") |
| |||
60 | Instance title connection on order is problematic as currently implemented | Instance connection of the POL on Open or Closed PO. Discussions at Acq SIG have raised concerns about the use of GOBI API as it's currently designed. From UChicago: If we end up with an order attached to the wrong record, we close the order, delete it, go to inventory, and delete the undesired holdings and items. Then we either adjust the import process to make sure it doesn't find an improper match (basically by taking out the ISBNs in the Inventory record, importing the data, then correcting the data in Inventory), or creating the PO by hand where we connect it to the right Inventory record. Per Dennis B "You could configure the GOBI integration to create Pending orders. This would mean a user actually needs to open them but you could also make adjustments to the instance connect before opening if needed." Need more analysis to determine the possible impacts of turning off automated matching. Talk to UChicago and Cornell about their experiences. 4/12/22 Acq SIG discussion of this topic. UChicago is loading every batch of the order batch load into a test system first due to these matching issues. Impact Untangling mismatched orders/instance/holdings could be time-consuming for acquisitions staff. | Moderate | Cost | Library staff | RM | Lotus includes the ability to disable automated instance matching (a new instance/holding will be created for all), Morning Glory will include the ability to edit an existing POL Instance connection. Create report to find duplicate instances. | ||||
61 | Historical Invoices Information | Placeholder to discuss the scope of invoices data migration to FOLIO Note from Virginia: this has only been important for e-resources in my experience. | Moderate | Cost | Library staff | n/a | RM | Yes | Waiting for data migration plan to define scope, mapping | ||
62 | Historical Arrive/Check-in Information | Placeholder to discuss the scope of data migration for information about previously received materials - the data captured in the Aleph arrival form and subscription check-in. Impact staff to spend more time researching issues. The Aleph subscription log is used to capture notes used in serials management. Losing access to this historical information about serials could cause | Moderate | Cost | Library staff | RM | Yes | Waiting for data migration plan to define scrope, mapping | |||
63 | Title search from "create new order" screen lacks enough info to find the correct title |
Impact increase in the amount of time it takes acquisitions staff to do their work. Backlogs of orders, invoices, and materials will develop, and patrons will experience delays in having access to newly acquired materials. When considered with other impacts on this list, what seem like minor inconveniences in using the system are likely to result in a significant | Significant | Cost | Library staff | RM | not scheduled (tagged as "morning glory candidate") |
| |||
64 | Key order data is split between order header and POL | Aleph consolidates key order info in one place. FOLIO requires the user to switch between the order header and the POL to review key data. This will slow staff down as they are looking for information. Discussions about this in the Acq SIG led to feature to hide fields when using templates for order creation to simplify the UI. This doesn't address the fact that key fields are split up - some on header and some on PO line. Impact When considered with other impacts on this list, what seem like minor inconveniences in using the system are likely to result in a significant increase in the amount of time it takes acquisitions staff to do their work. Backlogs of orders, invoices, and materials will develop, and patrons will experience delays in having access to newly acquired materials. | Moderate | Cost | Library staff | RM | Some features to help were completed in Lotus (modification to templates) |
| |||
65 | Routing lists for serials | FOLIO doesn't support the management of serials routing lists. This feature in Aleph is currently only used by the Law School library for 82 routing lists. Serial routing will need to be managed outside of the LSP which will impact staff productivity. | Minor | Capability | Library staff (Law only) | No JIRA created yet | RM | Not scheduled, no jira, discussed at RM SIG July 2021 |
| ||
66 | FYRO - Ability to process transactions against a prior year budget | FYRO as implemented in FOLIO's Iris release doesn't support the ability to process payments beyond the FY end date. Feedback was provided to the RM PO about our need to run FYRO 2-3 weeks after the end of the FY to processes any invoices that arrive up until 6/30 and to run reports to make sure one-time orders are paid/closed etc. The proposed workaround from Dennis B is to temporarily change the FY end date to extend into July to allow processing those transactions and then change the date back to 6/30 before running the Rollover process once we're ready. Dennis also said in slack, "Obviously this would be dangerous if there were a number of users in the system, so I don't recommend it." This is not a vetted process and we would need to test to make sure there wouldn't be unexpected consequences of editing the dates in this way. Impact It looks like there is a workaround in FOLIO (as described above), but we will need to test this and then it will cost staff time to coordinate changing the FY dates temporarily to ensure that the process is successful. | Minor | Capability, Cost | Library staff Risk that some payments intended for FY A would be charged against FY B instead due to FOLIO not allowing transactions after FY end date. | RM | Not scheduled |
| |||
67 | Order/Subscription log and notes |
Impact This will make troubleshooting difficult items (e.g. missing items) much more difficult and means less accountability when it comes to problems with issues. | Minor | Cost | Library staff | RM | Yes | Included in Orders data migration script. Waiting for a load of Aleph orders to FOLIO to validate that the data looks good in the target notes field. | Testing of this data migration is underway (4/12/22) | ||
68 | OCLC Integration - (duplicate of #11 above from MM) | Is overlaying or adding a single bib record as seamless in FOLIO as it is in Aleph? If not, we should include that impact here since it would slow the work of acquisitions staff. Info is available here about single record import in the Iris release. The wiki includes instructions for pushing a record from Connexion to FOLIO and for importing from FOLIO inventory. There is enhancement work outlined in UXPROD-2912, but not scheduled yet. To try this, login to the Lotus Bugfest environment (Login: diku_admin / admin). Open the Inventory app. Click "Action" button at top right. Select "Import." Choose OCLC World Cat and add the OCLC # of the resource to import. Click import. An instance is created. | TBD - not sure how well the OCLC integration works to evaluate priority | TBD - need to learn more | TBD - need to learn more. Need to investigate the OCLC overlay/add single bib process in FOLIO. | RM | not scheduled | Discuss with Duke MM Imp Team (see #11 from MM team on this list). | |||
69 | Item Status and Process Status Gaps | Placeholder for any gaps or impacts identified during discussion of Item status and process status. Need to have cross-functional discussions about end-to-end workflows such as binding to identify gaps and determine how items moving through this workflow will be tracked. | TBD - need to learn more | TBD - need to learn more | TBD - need to learn more | RM | |||||
70 | Order search is slow when volume of orders is high | Is this still an issue? This JIRA was updated on 6/15/21 by D. Bridges: "Opting into the "Load more" function of the search results component has improved performance here substantially. Limiting the number of results that will be displayed for any given search." Need to verify this after the full order load runs. Determine whether any next steps are needed to mitigate risk, such as creating a custom table in the LDP to store closed Aleph order data rather than loading it to FOLIO (just in case). Impact hen considered with other impacts, what seem like minor inconveniences in using the system are likely to result in a significant increase in the amount of time it takes acquisitions staff to do their work. Backlogs of orders, invoices, and materials will develop, and patrons will experience delays in having access to newly acquired materials. | Moderate | Cost | Library staff | UXPROD-2364 | RM | Implemented - need to verify through testing | Test order search performance once full volume of data has been loaded. |
...