Date
...
Attendees
Discussion Items
| Time | Item | Who | Description | Goals/Info/notes |
|---|---|---|---|---|
| 2min | Administrivia |
| ||
| 15Min | Go live reports | Andy Horbal and all | ||
| 45 Min | Title level requests | Continued discussion and updates on TLR Homework from last week: If we were to add some field or an indicator to describe what state the request originated in, where would that go? And what would it be called? | Link to Google folder of mockups. We looked at 15-request-on-instance.png. It has been updated based on our conversation. |
Meeting Notes
Andy said that implementation of FOLIO at Cornell on July 1 has generally gone well. On the performance side there were some issues with slow response times for check-in/out and requests. EBSCO was able to help with these issues on a case-by-case basis and resolved them fairly quickly after their being reported. Problems may have been due to local setup conditions. Slow check-ins when there were a lot of items was more of a browser problem than a FOLIO problem, and ending sessions more frequently fixed this.
Other problems were with Bursar Feed not working, Finance in general having problems. ILL having difficulties, and related to this was the problem of ILL service point pickup location not being checked. Initial problem with the patron feed (inactive status for patrons that should have been active) was soon fixed, as was the problem with notices not being sent. BorrowDirect was also not working properly. Card Reader problems were fixed by re-programming the card readers when possible; some card readers will need to be replaced.
Contrary to concerns, Data Import and Batch Processing did not cause any sluggish behavior with FOLIO.
On the training side, it was noticed that some of the branch libraries were not doing any requests. Some staff needed re-training on how to enter requests.
Staff have been submitting feature requests based on their experience with FOLIO, which Andy will share with the SIG at a later time. Customizing pop-ups by service point was one feature requested.
Stephanie asked the group about handling recalls for title-level requests.
Two common approaches to handling recalls are i) recall a specific item and stop renewals on the other items (that could fulfill the request) or ii) issuing a blanket recall on all items that could fulfill the request. Consensus of the group was that the best initial approach would be for a recall to be placed on the item at the top of the queue rather than placing a recall on all items. Placing a recall on all items can cause confusion for patrons, and could be difficult to implement as FOLIO does not have a good way of canceling recalls. It was agreed that for now, the item to be recalled should be the item with the earliest due date, with the item that has been checked out for the longest time as a tie-breaker. It may be desired in a later version to allow for a more complicated method, such as recalling items borrowed by undergrads before recalling items that have been checked out by faculty, etc.
Issue was raised as to how to have FOLIO handle the situation where a recalled item is not returned when it should be – need a way to prevent the recall from getting 'stuck' and never fulfilled if the item that is recalled never gets returned. Proposal was that there be an automated way in which if the recalled item is not returned by its recall due date, then the item with the next earliest due date has a recall placed on it. It was recommended that having this be an automatic feature or not should be customizable in the settings, as some institutions may prefer to re-order things manually.
Darcy raised the issue of whether there needs to be an easier way to see what items have overdue recalls/requests on them, so library staff can check if they need to manually re-order the queue. Currently Request Search does not show due dates, Requests Results List does not have a column for due date. Request Detail does show due date, but due date not currently facet-able. It was suggested using either tags or item status to allow search for overdue recalls.
Stephanie then asked about the handling of blocking requested items from being renewed.
There should be a way for patrons to see in the Discovery Layer if an item has a request on it, and cannot be renewed. Library staff should also be easily able to see which borrowed items have been requested, so they can explain to the patron why the item can't be renewed.
It was previously determined not to have a 'recall status' because this should wait until the tripartite item status system is implemented (see Updates from item status group and Item State in FOLIO. Development of the three-part item state is not currently underway, but sentiment was expressed that developing it should be made a high priority. A three-part item state would make handling title-level requests/recalls easier.
It was recommended that for title-level requests, the policy should be to have one item be recalled with holds placed on the other items that could satisfy the request. Then the same policies that have been configured for recalls/holds would apply, i.e. if the institution has a policy of allowing renewals on items with holds, then that would still apply in this case.
Meeting Outcomes
Functional Area | Product Owner | Planned Release (if known) | Decision Reached | Reasoning | Link to supporting materials | Comments |
|---|---|---|---|---|---|---|
| e.g. loans, fees/fines | Name | e.g. Q4 2018, Q1 2019 | Clearly stated decision |
| e.g. mock-up, JIRA issue | |