Because FOLIO is a rapidly changing system, and libraries are adopting the system at different stages of development, it's important to know what features are planned but not yet in place, and to understand workarounds that may be possible until those features are ready. This page is meant to track that information for adopting libraries.
| Issue | Functional Areas | Jiras (if known) | Description of issue and workaround (if known) | Documentation |
|---|---|---|---|---|
| Limits of the Item State model | All | UXPROD-1321 - Getting issue details... STATUS | 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 will 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. | ||
Delivery requests do not have a designated delivery service point | Resource Access | UXPROD-2429 - Getting issue details... STATUS UXPROD-2648 - Getting issue details... STATUS | 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 | UXPROD-2156 - Getting issue details... STATUS | 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 | UXPROD-1710 - Getting issue details... STATUS | 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 | UXPROD-90 - Getting issue details... STATUS | 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 that need to be cleaned up as well. | Delete a loan using Postman |
Handling title level requests (since as of Feb 2021 only item-level requesting exists) | Resource Access | |||
How to delete a user record via API | Users | UXPROD-2388 - Getting issue details... STATUS | Delete a User Record using Postman | |
How to do a bulk change of due dates using API, including considerations with notices | Users | UXPROD-2375 - Getting issue details... STATUS | 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 | UXPROD-1275 - Getting issue details... STATUS | 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. 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 Checkouts |
| Recording productivity statistics (e.g., cataloging, record maintenance) | Inventory | UXPROD-2867 - Getting issue details... STATUS UXPROD-2863 - Getting issue details... STATUS | 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. |