Reading Room Workflow - National Library of Australia

General overview of NLA Reading Room requesting

in FOLIO

NLA operates a closed stack. All requests to consult material must be placed as a callslip request for retrieval (a FOLIO Page request). Material is retrieved from stacks (including offsite repository, as needed) and is delivered to the appropriate reading room. Patrons can consult material in the reading rooms only, and the material is held in the reading rooms at the Hold desk for the duration of the patron's 'loan' period, unless sent for return by the patron in the meantime.

In implementing this general flow in FOLIO, we had to work around some gaps in functionality and adapt to the way in which FOLIO expects a circulation flow to work - which seems to presume patrons will check out material from open shelves.

Details of our steps and what we had to do noted below:

Patron initiates a Page request for material they have found in the OPAC (Blacklight), according to item requesting limits by patron group

FOLIO allows item loan limits to be set (in line with expectation of open shelf checkout), but not yet requesting limits (although this appears to be in discussion in the community).
To prevent unlimited requesting by patrons, we added functionality to our OPAC back-end services to check the FOLIO item loan limit for the patron's group, check how many open loans and requests the patron has, and prevent requesting beyond that.

Check for 'multipart' items and have patron specify the sub-part required.

NLA does not generally maintain individual item records for 'multipart' materials (e.g. Manuscript collection boxes, serial titles with issues, map sheets in series etc) as these may have hundreds of parts.
In these cases we present a form to allow the patron to specify in free text the part they require (e.g. Vol. 2. no.1, 1988; Series 2 - boxes 3-6).

Under Voyager, this was handled with 'items-on-the-fly' being created, and we have adapted this approach under FOLIO, mediated by the back-end services we wrote for the OPAC to FOLIO. Taking a serial example:

When a 'multipart' item is requested, show a form to have the patron specify the issue they require
Duplicate the single item record that represents the whole serial title to create a temporary item-on-the-fly, with all the same details as the main item, but with a temporary barcode for circulation, and enumeration details as requested by the patron.
Immediately place the patron's Page request against this temporary item (with distinct barcode and enumeration).
Request is submitted to FOLIO, and appears in the requesting queue for retrieval and fulfilment.

Another aspect of requests that we control via the OPAC back-end services is setting the Pickup service point.

In FOLIO, patrons are able to select their preferred pickup service point for material.
However, for NLA, we require certain materials to only be used in particular reading rooms (special collections, newspapers and microforms), so we force the pickup location to be set at the time of request, based on the material location code.

3),4) & 5): Queue monitoring, callslip printing, retrieval and delivery:

Stack staff monitor requests for their stack locations, print paper callslips for material in their locations in batches for retrieval, and retrieve and deliver material to reading rooms.
Callslips have essentially duplicate request information on top and bottom halves, which are split on retrieval: half stays on the stack shelf as a placeholder; the other half travels with the material.

FOLIO does not currently support everything we needed out of the box, so we had to write our own mini helper applications to work around these gaps for us in the meantime for go-live. Our intention was to only maintain these helper applications until the equivalent functionality arrives in FOLIO itself (but that may take considerable time).

Our helper application for requests allows:

Filtering for monitoring of requests by relevant stack retrieval service point.
FOLIO has a single request queue and currently only supports filtering on pickup service point, not stack service points where retrieval staff are working.
Printing of single callslips or a subset of callslips for any stack retrieval service point.
FOLIO supports printing ALL callslips for a service point that the staff member has set as their current service point. We needed to be able to print one, some or all callslips on demand to suit our stack retrieval workflows.
Customised callslip printing

FOLIO callslips have limitations on the item bibliographic information and request information available, and limited control of layout. We wrote our own callslip printing (including barcodes) to add extended bibliographic information to aid retrieval, and to control layout consistently for 'top and bottom' perforated callslip printing.

Switching requests to a different 'virtual queue' for alternative request routing.
In some cases we need to re-route a request to a different retrieval service point (e.g. where large collections may be split in multiple locations) .
FOLIO would normally need the requested item to be assigned a different effective location to switch which stack service point it would be associated with.
We adapted using tags on the request to simplify making the request temporarily appear in a different service point queue in our helper application without needing to edit the item record location.

Material is delivered and checked-in to the hold shelf of the appropriate reading room (as set at time of requesting). Patron is notified that material is available. It is not yet checked out to them, but is held awaiting collection (according to what would be the usual 'loan' period for the patron group). If not collected by the end of this time it is 'weeded' from the hold shelf for return to stack.

Material is checked-out to the patron when they come to collect it.

The patron can consult the material and either place it in returns to go back to stack (if they are done with it), or to continue to be held at the reading room desk for consultation another day (until it is manually weeded for return by staff).

Material is checked-in on return to stack

On return, material is sorted for return to stack, is reshelved and the on-shelf callslip is removed and is used to check the material back into 'home' location - discharging the loan from the patron.
A patron can also request that the material be checked in at the reading room desk, so that their loan is discharged and does not count against their request limit.

Clarifications

'HOLDS' on the diagram is just the physical chute a patron places material in when they want us to hold it at the circulation desk for consultation another day (or they pass it back at the circulation desk if there is a large amount on a trolley, or fragile material etc). We aren't doing anything with FOLIO 'Hold' requests in this case (or in general).
Material is placed back on the hold shelf for patrons to collect it another day (within the period we will hold it - usually 7 days from date of request for general patrons and material in Main reading room.)
We don't do anything to check it in again at the hold desk this point in FOLIO. If we did, FOLIO would treat that as a return against the loan and put it back in transit to its 'home' stack location - which is not what we want.
Next time the patron collects material, we scan it in Check Out again. FOLIO shows a message that it is already checked-out. It does not do anything to extend the loan period etc.
We do this mainly so that staff don't need to sort whether there are items in the set of material a patron collects that have already been checked out to them on a previous day versus new material requested that has arrived in the meantime - it just all gets scanned again. We are still seeing how that settles in practice (especially for large sets of material) and may adjust our manual process to suit.
We largely stayed with manual processes at the circulation desk because we did them that way under Voyager (because our preferred procedures didn't quite fit Voyager's limitations or expected flows) and now because FOLIO similarly doesn't yet support everything we want perfectly. For example, our 'loan periods' and 'hold periods' are in policy and practice from the date of request (not the date of check-in at Hold shelf, or check-out to the patron on pickup) - and are manually managed based on the request date on the callslip kept with the material.