Page tree
Skip to end of metadata
Go to start of metadata

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.


IssueFunctional AreasJiras (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: addressResource 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 noticesResource 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

UXPROD-1796 - Getting issue details... STATUS



How to delete a user record via API 

Users

UXPROD-2388 - Getting issue details... STATUS

This will be available as of the Kiwi release (R3 2021). Hooray!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.


Inability to batch send lost item fee/fine noticesRA

UXPROD-2252 - Getting issue details... STATUS

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 a 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.


  • No labels