Current Problem:

Currently in FOLIO, there is no way to filter Requests by the Service point nearest where titles/items are shelved (a.k.a.., Retrieval service point). The FOLIO community, including Cornell, NLA, and the Library of Congress, wants to be able to filter based on the Retrieval service point.

Use Cases:

• Library divisions need to filter by Retrieval service point in order for certain staff groups to fill requests for their own custodial division and make efficient use of their time.

• Libraries field many requests across several retrieval locations. Circulation staff wants to be able to filter on Retrieval service point in order to view patron requests that will be retrieved at particular locations as efficiently as possible, easily adjust queues, and use location filters to see which branches may need extra copies of physical items.

LC Use Cases:

There are three considerations we have for the ability to filter requests by retrieval service point and they all relate to the volume of requests we receive: across our current queues, we receive an average of ~400 requests per day (with maximums near 700) excluding congressional requests, and we assume this number will grow once we enable holds for most patron groups.

1. We are very excited about the work completed as part of , which allows for selection of pick slips to print. This will be used every day by our onsite general collections retrieval staff, but will not be practical if they need to manually search through the other ~300 requests in the system (for other service points) to find requests related to their retrieval service point. This would drastically reduce the efficiency of the onsite general collections retrieval staff, and they may not meet their expected response time policy due to this change.

2. Our offsite retrieval staff, who field the majority of the requests (and average of ~300 per day), are hoping to utilize the CSV export capabilities paired with the selection of pick slips in order to export a list of new requests in order to organize retrieval and pair with external systems. This would be a similar issue to #1, where this would currently require them to manually check the boxes of 300 requests before exporting.

3. The general collections and offsite collections comprise the majority of requests, but there will also be two other divisions of the Library who will be managing a small number of requests for their collections (Asian Division and Law Library). Similar to #1, these folks will be searching for needles in the haystack of the requests list. Although they could do this and the expected response time isn’t as fast, the concern here is more about human error and affecting the retrieval of general collections and offsite material by inadvertently selecting the wrong slips to print.

LC Assumptions:

• We assume that the CSVs resulting from the Print Pick Slips and Print Search Slips actions will not be affected by using this filter

• We assume that this filter can help target requests to be selected for the Print Selected Pick Slips and Print Selected Search Slips actions

• We assume that usage of this filter will affect what is included in the CSV export for the Export Search Results to CSV action (i.e. we assume this will work like the other search and facet options in the Requests App to filter the results list, which can then be exported to CSV)

In Scope:

1. Add a new “Retrieval service point“ filter in the Requests App

   • A single-select drop-down option to select one retrieval service point at a time would be sufficient (the multi-select is nice to have and LoC can reassess the need in the future if its not included in LCAP Phase 2 Go-live, but can be delayed if it helps reduce workload).

2. Filtering requests by retrieval service point.

   • The new filter should apply to both hold and page requests, filtering by the retrieval service point based on the primary service point of the item’s effective location.

   • The filter should work alongside existing filters in the Requests App.

   • [Update 11/15] The filter will work only with newly created requests and will not filter previously created requests.

   • [Update 11/15] The filter should contain all tenant service points that have a location assignment.

   • [Update 11/22] If the item location or primary service point has been changed, these changes will not apply to already created requests. However, the updated location will be considered when filtering new requests.

3. Add an option to display the “Retrieval service point” as a column in the Requests results pane. This column will be unchecked by default.

4. Ensure compatibility with the following print actions:

   • Print search slips (hold requests)

   • Print pick slips (page requests)

   • Print selected pick slips (page requests)

   • Single print for pick slips (page requests)

5. Ensure that filtered requests can be exported to CSV for external use.

Out of scope:

• Print selected search slips and single print for search slips (hold requests).