2019-2-11 Resource Access Meeting Notes

We're going to hold off on Thursday meetings for the next couple of weeks while our POs finish up with their push for Q1. Please leave them on your calendars, because they'll be back.

- Should recall requests automatically go to the top of the queue (probably below rush recalls, when we have them) behind any existing recall requests?
- What happens if the request queue is manually re-ordered and a hold is put above a recall in the queue?

- Considerations:

-- We've said renewals should be blocked on items that have been recalled - do we only look to see if a recall is in position 1 of the queue or should we block renewals if there is a recall anywhere in the queue?
-- What about shortening of the loan period that usually occurs when an item has been recalled (based on the recall return interval and minimum guaranteed loan period)? Do we only do this when the request in position 1 of the queue is a recall?
- Current thinking is that only looking at position 1 of the queue is the simplest and most understandable
- What use cases should we consider?
-- A request was originally created as a hold but is now more urgent.
-- A request was originally created as a recall but is now less urgent.
-- Other uses cases? What are the use cases for manual request queue re-ordering?  

• Because...
• Because...

• Because only Chicago has an automated storage facility

• Integration with automated storage facility
• Typically there is a DB outside the ILS
• ASR vendor has done some custom programming for integration
• The requests table is polled for ASR requests
• It might work to poll for page requests with an ASR location
• Really something is needed to identify that this is a request for ASR
• But ideally it's a separate request type
• The discovery layer looks at the status of an item (at Chicago, there is a status "Available at auto storage" and, if the item has that status, the discovery system knows to create the ASR request

• Everyone has offsite/remote storage

• The solution for this and ASRs may be the same
• At Lehigh, some of the remote storage is special collections and there are workflows needed for approvals
• Will come back to this discussion later

Requests (Request Queue Management)

• If something is awaiting pickup, nothing should be able to jump it in the queue (because a notification has already gone out to the requester)
• You shouldn't be able to request something you currently have on loan (users game this loophole for recall wars)
• If the top item is a recall and it's cancelled, it would be great if FOLIO would extend the due date again for the current borrower (nice to have feature that many systems don't have today)
• Yes, recall requests should automatically be prioritized over holds in the requests queue
• This automatic queue management is essential
• Manual queue management is also essential so you can manually prioritize some recalls over other recalls or some holds over other holds
• The system doesn't need to support prioritizing a hold above a recall as that would be extremely rare could cause problems and they could find a workaround
• If we offer the ability to manually manipulate the request queue plus the ability to change the due date in a request, people would not need Rush recalls
• Manual manipulation of the request queue is higher priority than rush recalls.

• FIFO queue management actually works for Chicago, but they are an outlier
  • Patron requests all for ILL
  • Circ staff manually converts to recalls only if item not avilable via ILL
  • Holds are only done on On order or In progress items
• Five Colleges doesn't have a request type distinction in their current system and doesn't understand how the patron should know which type of request they want
  • Cate said this sounded like Chalmers' current setup
  • They plan to implement only Pages and Recalls so there is never a choice to be made by the patron (the system knows which one to create based on item status)
• Cornell lets patrons choose whether they want to create a hold or recall by asking them whether they need it right away or can wait until it becomes next available