Brainstorm page for the availability interface

What's needed to display proper actions(buttons) and information to an item in a discovery system.

This intended as a unstructured collection of needs, wishes, use cases, etc.
Please add any thoughts. Don't care about duplicates or potential already supported functions.
In the upcoming discussion it's much easier to drop a point than to find a missing one.

#Title / Key

Who (optional)

DescriptionOpen questions


Tickets, facts and comments by the investigatorsPriority item?
1Individual availability
(Availability in different contexts)

Different media types have different types of availability. To respect this, this availability should only published with the context.
One Item might be (un)available for:

  • Physical access in the house
  • Online Access in the house
  • Physical access at home for members of the institution  (loan)
  • Online access at home for members of the institution (remote, proxy)
  • Sequestered access for digital use (Controlled Digital Lending)
  • Physical access at home for members of other institutions (ILL)
  • Copy access at home for members of the institution (ILL)
  • Online access at home for every one (license free remote access)


Meeting: R3
As general reminder of completeness.

2LimitationsThe general availability of an item may be limited by some reasons. e.g.
  • physical items: "Only against an deposit", "Not on Mondays", "Please ask"
  • online resources: "Moving wall license, not the current year", "Concurrent license, only from IP range, ..."

Uwe: R2
(perhaps solved by displaying notes)
see #10
see #4
3Pickup LocationsSometimes items need to be restricted to as subset of all possible pickup Locations. (e.g. only into a reading room or only limit to the the pickup locations of one department/area) see UXPROD-2689
Uwe: R3, but needs UXPROD-2689see #23
4Additional informationUwe Reh To decide which item to request, a patron might need additional information. (e.g. "First three pages are missing", "Today's newspaper as handout, might be lost.")

Uwe: R3 (Visibility of notes)

see #2
see #10

5HRIDUwe Reh 

API should  accept  UUID and HRID  for the requested instances.
API should provide  UUID  and HRID for the items.

R1 for request
R2 for resonse

Chalmers: ?

Demian: R2 (VuFind would be less efficient/flexible without this capability)

Laura: R2/R3


6Direction to other systems - not available

If an item is not available, we want to be able to direct the patron to another request path. E.g., if all the copies of book X are unavailable, provide a button that sends the patron to an ILL system to request a copy from another library.

Uwe: Is the redirection to an ILL system a task of the availability interface or a task of the discovery system?
Should the availability interface be able to list all alternatives like ILL, buy request, AEON, ...?

Meeting: R4/R5

7Direction to other systems for requestingIf an item can be used but the patron needs to request it in another system, the discovery layer should be able to support that. E.g., library uses FOLIO to circulate its main collections but AEON to provide access to special collections, the discovery system must know that an item should present the AEON request path and not the FOLIO request path.
Meeting: R4/R5

8Provide a simple way of determining which delivery methods are available for a given item/patron combination

Determining whether an item can be paged, recalled, or put on hold requires (I think) making two API calls (to the request-policy and  request-policies endpoints) and filtering the results by item status (e.g., charged or available). It would be great to be able to simplify this on the discovery system side.


  • (thumbs up) one possible context of my 1st. point
  • (thumbs down) simplification sounds nice but we should not overlap the APIs for items and for patrons. RTAC should provide 'Limitations',  'Pickup Locations' ans 'Additional information' for patron groups (roles) and PATRON should provide the role of the particular patron. (see "Patron aware" information)

Does this overlap with the need to be able to have a list of valid pick up locations (based on patron and item information) when the patron makes a request for the item?

Chalmers: R4

Uwe: R2


see: #17

KG: This seems like a patron interface requirement.


This wish addresses both 'rtac' like 'parton'. Or something in between like a 'PaRtac' (smile)
The problem is, 'availability' is not only related to an holding/item. 
The 'availability'  is also influenced by the circulation rules (parameter: patron's group, ...) and individual settings (locked users, patron's option: delivery service, ...)
Certainly UXPROD-2422, UXPROD-2758 and CIRC-214 are related to this question too.

In our consortium we are currently working on problems like this. If possible, I'll share a white paper with use cases in the next days.

9Estimate delivery time dayMatt Connolly 

If an item can be requested, provide an estimated delivery time (number of days) for that type of request. This might be a simple setting in Circulation, or it could factor in material type, location, existing requests for the item, etc.

Uwe: (thumbs up) Also for recalls

Uwe: Is Folio itself providing this informations?
e.g. as property of a location

Phil: could depend on user too.
Uwe: so it is related to #8

Uwe: R2/R3see: #15
10Terms of useRobert Scheier 

Terms of use info. from FOLIO Licenses need to be available in Discovery, e.g., concurrent use, ILL, etc.

Uwe: see #2 (Limitations)

KG: This functionality is already available - UXPROD-1755 - Getting issue details... STATUS

Uwe: If I got it right, the information is available in the UI but not rtac's response

see #2
see #4

11Serial Data Display (Items) 

Relevant data from Enumeration, Chronology, and Volume fields should be clearly and uniformly displayed to patrons.

Uwe: (thumbs up) (Additional information)

Laura: R2 (R3 if this can easily be solved via additional API calls)

KG: Is it preferred that we always returned this information and not have the current conditional logic What gets returned in edge-rtac response
12Serial Data Display (Items)Robert Scheier 

Piggybacking on Jack's comment above, volumes should display in sequential order. Right now in FOLIO and VuFind the order is not sequential if you add items out of order.

Laura: R2 (R3 if this can be easily solved via additional API calls)

see #18


BTW - how else should sort RTAC results by?


Requests when no items

Offer an alternative solution to request instances that have no items. 

Uwe: no items? → buy request? Journal with just one holding but no items
(instance → holding → item)
Marie: Thinking of e.g journals records that doesn't have items. Be directed to a form/to an e-mail where I can request a specific issue.

Chalmers: R1

KG: Is this possible by creating a custom link on your OPAC/Discovery service layer? 

Uwe: Yes a custom Link, might be a workaround for this and a lot of other needs mentioned in this spreadsheet.
But when the Discovery layer is a hosted service (not self maintained by the library)  the library should be able to tunnel such a link

14Allow title level/item level request depending on instance type.

Assuming title level request is default, enable item level request when appropriate, e.g. serials, journals. (For this type of instance only show item level request.)

Marie: Thinking of e.g journal records that has items. Possibility to select a specific issue to request.

Tod: Here is an example of multiple copies of a monograph:

Here is an example of multiple copies of a multi-volume monograph:

Tobias Gostomsky : A different Use-Case: We sometimes have media in different branch libraries and no transport between libraries. Customers are not always interested in placing a TLR everywhere, but e.g. only in a specific location.

Chalmers: R2

Laura: R2/R1

y - especially for folks using TLR
15:See number of unfilled requestsMarie Widigson kristin.olofsson 

The patron should see the number of unfilled title level requests on an instance, before placing the request (not having to be logged in. Based on this information he/she can make the decision if it's worthwile to place a request or not.

Uwe: Queue length? Shortest 'Estimate delivery time of all items?
(item request == queue size * x    -   Title requeset == min of items ?)
Marie: The queue length. The number of current open requests. (Not delivery time, it's very hard to estimate.)
The number of title level requests can be found in FOLIO UI so I imagine it should not be too difficult to get.

Chalmers: R3

Laura: R3 for title level R1 for item level

see: #9y
15aSee number of already existing holds for checked-out itemsIf title level request is unset:
With this information - in combination with the due date of the checked-out item - the patron can decide, if it is worthwhile to place a hold.


16Display adjusted item statuses

Several item statuses are very hard to understand for the patron (e.g.  "Aged to lost" & "Claimed returned"). The best would be to add a "discovery display name" already in FOLIO where the library could rename statuses for the discovery layer and have these displayed to the patron instead. (See UXPROD-2636).
Uwe: Like in the Patron page? Status-id and status-text in one language?

A second best option may be to add a "translation table" for item status ID:s to library specified statuses in the discovery (e.g. "Aged to lost" & "Claimed returned" should be be displayed in the discovery as "Unavailable".)

Marie: This seems to be captured by (OLD ACCOUNT) Erin Nettifee in UIIN-1170 - Getting issue details... STATUS  

See also

17"Patron aware" information

RTAC should provide information relevant to the specific authenticated patron (if available) in the RTAC response (i.e. is this item loanable, the initial loan period, requestability, lost item charges, and late fine rate). Ability to retrieve preferred pickup location, preferred fulfillment method, delivery addresses, block status when attempting to place a request would also be helpful.

Uwe: IMHO RTAC should be agnostic on the patron. Please, "specific authenticated patron" only as option.
BTW. Shouldn't "Lost item fees and late fees" be part of the master data in the patron interface? The same goes for "Preferred pickup location, preferred fulfillment method, shipping addresses and blocking status".

patron group vs. individual patron idGBV R4

#see #8


18Sorting of monographs itemsMarie Widigson kristin.olofsson RTAC should sort the holdings and items for a monograph with equivalent items by a defined logic. For example all holdings for Main library at the top, all available items at the top. This need may be different by different institutions and therefore customizable. (Currently in RTAC API response, our items are sorted in a for us seemingly random order.)

see #12


BTW - how else should sort RTAC results by?

Homework: Each institution enters their thoughts on fields to be used for monograph sorting in MODRTAC-95.
A customizable primary and secondary sort option could be good.

19Handling of many items


RTAC seems to be slow

1,600 items, Colorado Revised Statutes

see: #20

  • edge-rtac > add paging logic with system level parameter? 
  • cache support? 
  • streaming? 
  • Understand differences with inventory APIs and edge-rtac 
  • Has improved with EDS classic (Chalmers) BUT it is still slow regardless of number of items returned. 
  • edge-patron slowness with renewing 200 loans 

Runs fairly  quickly- -

General problem?
GBV: 1 ?see #19!!

Retrieve both holdings and Item information at the same timeBrooks Travis 

Some institutions wish to use both holdings and items and this currently requires two calls to RTAC. Perhaps especially relevant for serials information.

Question to all 

What field(s) that could be used to drive what is returned in RTAC?

Material type (item in Germany and FRBR always instance)
Mode of issuance ( instance) 
Nature of content (instance)
Awareness of holdings statements and item  

RTAC is called, to get availability information about a known instance. 
So I don't see any need for any attributes of the instance. (Material, insurance, subject, etc. is already known).
On the other hand, RTAC cannot provide too much information about the 'holding' and 'item'.
Locations, licences, restrictions, pickup locations, additional info, etc. Short, everything which is asked in the other rows

Chalmers: R3

Laura R3


KG: We definitely need to do this and I think it may help with the above request tooy
21Create a fake item record to support electronic resources Khalilah Gambrell Discussed in 2/7/2024 meeting

22Single request for multiple items

For performance reasons we would be in favour of having a single request/response for multiple items. E.g. all items visible via AJAX. 

Uwe: Isn't RTAC Batching that what you are looking for?

Björn Muschall Can you provide a example or scenario of the problem that your description would solve?

23Remove patron choice of pick-up location and default to effective location's service point.  Kara Hart Allow institution to remove display of pick-up locations for patron when making a request.  For institutions that want the request's pick up location to be the effective location's service point.  For institutions that cannot transport materials to other service points for request pickup.  (Currently our staff have to change pickup locations of items in FOLIO when patrons choose a different pickup point, before we can process the requests)

Hey Kara Hart 

  1.  Doesn't this logic belong in the discovery layer?

2. Are you really looking for just a list of valid pick up locations for the specific item?

There is a Jira for "specify the list of pickup locations for a request" - UXPROD-2689 - Getting issue details... STATUS

Uwe: I assume, this is the same need as "Pickup Locations" (above). Before being able to provide a list valid locations in the API, UXPROD-2689 has to be solved first.

The 'patron's choice' should be marked as the list's default value.

Uwe: R3 (as part of  #3 'pickup locations')

see #3
23Allow for a request to be processed as a recall even if a hold is also allowed(OLD ACCOUNT) Erin Nettifee 

Currently, if a request is associated with a policy that allows for a hold and a recall, the request will always be placed as a hold. This is undesirable if institutions want recalls to occur if the item is out on loan, because recalls trigger notices and due date changes while holds do not. 

Most institutions with this configuration find that the high majority of requests are ones where recalls are appropriate, but there are still use cases for holds (e.g., if staff are placing them for processing needs but don't need to require the patron to bring it back early.)

Sorry for asking, but is this a demand for the (discovery) APIs or rather one for the librarian's UX view on FOLIO?