Page Comparison

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

Use of the Item HRID will 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

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.

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. 

Manually managing claim returned items (before functionality is fully available)

Deleting a loan 

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. 

Handling title level requests (since as of Feb 2021 only item-level requesting exists)

How to do a bulk change of due dates using API, including considerations with notices

Handling offline checkouts

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.

Workaround 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

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.

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.