...
| Issue | Functional Areas | Jiras (if known) | Description of issue and workaround (if known) | Documentation | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Limits of the Item State model | All |
| FOLIO's item state model is intended to encompass three parts - availability, needed for, and process. As of Iris, only Availability is implemented. Libraries will find that they need workarounds to be able to track staff processes and other needs for item workflows | Item State in FOLIO - see "Considerations for Implementers in 2020 and 2021" | ||||||||||||||||
| System does not auto-generate a system supplied number for the Item Barcode Number, when no "sticker" barcode is available. FOLIO does not currently have a number generator that can be used to use for intellectual barcodes. | All | Use of the Item HRID could be used in the Item Barcode field whenever an item record is required but no barcode sticker is available for labeling and scanning into FOLIO. Other use cases are for materials that need an item record but would never have a barcode sticker. For example, electronic resources in Courses, issues of periodicals prior to binding, materials still in the order process, etc. These types of barcodes are colloquially known locally as 'dummy' or 'intellectual' barcodes as opposed to 'real' barcodes that come on stickers. See Creating Fake Barcodes in Excel for how to create a repository of placeholder barcodes if it's useful for your library. | ||||||||||||||||||
Delivery requests do not have a designated delivery service point | Resource Access |
| Delivery request functionality was implemented without a key piece of functionality - requiring a designated delivery service point. As of Iris, a delivery request is triggered whenever the request is checked in at any service point. No workarounds within FOLIO have been identified yet. | Manually Managing Delivery Requests | ||||||||||||||||
| FOLIO only sends patron emails from one reply-to: address | Resource Access |
| All FOLIO emails come from one tenant-defined address. Libraries with multiple branches / circulation departments may be coming from systems where they could control the reply-to address more directly (e.g., emails about main library materials came from main-library@, emails about science library materials came from science-library@, etc. There are no FOLIO-defined workarounds for this. Outside of FOLIO, libraries could use Outlook forwarding rules, mailing lists, or external ticketing systems like Request Tracker to manage traffic. | Managing Multiple Branches with Only One Reply-To Address | ||||||||||||||||
| Inability to reprint / resend notices | Resource Access |
| As of Iris, patron notices can only be sent via email, and if there are problems with those notice deliveries, there is not an easy way to resend the notices | Manually managing claim returned items (before functionality is fully available) | Resource Access | |||||||||||||||
Deleting a loan | Resource Access |
| FOLIO uses the language of "cancelling a loan". There are several scenarios where libraries would want to do this, but the basic scenario is if a loan truly happened in error, AND/OR the error is stopping an associated workflow (like an integration with a self-checkout system or ILL.) There are no UI-related ways to do this right now. You can delete a loan with an API call to DELETE /loan-storage/loans/{loanId}, but there are also associated pieces with notices and potentially fees/fines that need to be cleaned up as well. | Delete a loan using Postman | ||||||||||||||||
How to do a bulk change of due dates using API, including considerations with notices | Users |
| FOLIO has a feature for automatic renewals that is not yet developed. In the absence of such a feature, libraries may want the ability to do a bulk change of loan due dates using an API call (and in fact may prefer that approach in general for scenarios where due date changes are needed, rather than incrementing a loan's renewal count.) This has been something many libraries had to do as part of COVID response. | |||||||||||||||||
Handling offline checkouts | Check Out |
| Because FOLIO is completely web-based, if a library's internet access goes down, they will lose access to FOLIO. Traditional ILSes generally offer support for continuing some transactions when internet access is unavailable, but FOLIO does not have this service yet. The Jira does not have any work planned. A workaround for libraries would depend on the library's service desk structure and customer service expectations. There is no specific workaround yet identified. Handling Offline CheckoutsWorkaround options include 1) Not circulating when FOLIO is offline (not usually viable if an outage is planned) 2) Track checkouts in an Excel spreadsheet 3) If your library is hosted by EBSCO, use their Android or iOS Offline circulation apps | |||||||||||||||||
| Recording productivity statistics (e.g., cataloging, record maintenance) | Inventory |
| There is currently no element in the Instance data to record productivity statistics that is not tied to underlying source data. Until the Administrative note is implemented, these statistics could be stored in a Holdings note, e.g., create a holdings note type "Productivity." Once the Administrative note is implemented, libraries could choose to store delimited strings in it that could be mapped later to the fuller element outlined in UXPROD-2863. | |||||||||||||||||
| Inability to batch send lost item fee/fine notices | RA |
| Right now, aged to lost emails send one by one, and are not batched. They also send one by one for lost items and replacement costs. The workaround is to use an overdue notice with a date/time trigger (which does batch and send overnight for multiples) and send a notice the day an item goes aged to lost, telling the patron that the items have aged to lost and directing them to a webpage to see the charge. Then, do not send an aged to lost notice.As of Iris, the scheduling of aged-to-list processes is up to individual hosting providers, so the timing of this is up to the individual school. Ideally you would have the item age to lost shortly before the fake aged - to - lost notice is batched and sent. |