ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
requestIdproductVersionrequest_titlerequest_descriptionComplexity PointsExplanation of complexity pointsnotes
2
8481RapidILL/Rapido/ALMA RSRapidILL: Option to include title/verso pages in chapter requestsSome RapidILL member libraries prefer to receive book chapter requests including the Title page and Verso (Copyright) page to provide additional context for referencing. To facilitate this, please could an additional checkbox be added to the Alma Resource Sharing form, appearing once the chapter or specific pages checkbox has been checked. This could be positioned directly below the chapter or pages checkbox, or below the form field for pages. A corresponding checkbox could be added to the Request Attributes section of the Lending Request General Information tab.
Alternatively, could a configuration setting be added, which enables libraries to default the choice to have Title and Verso pages included in their chapter borrowing requests?
Or, if it is deemed important for all members to provide Title and Verso as standard, could the RapidILL terms of service be amended to make this a mandatory step for member libraries when providing book chapters in answer to RapidILL lending requests?
11The complexity points we will assign to this requirement are based on the following proposed solution.
The borrowing institution can set a parameter requiring the title/verso to be added to the digitized scan. This will affect all digital requests sent to Rapid for all the libraries in the institution.
3
8484RapidoConfiguration option for mandatory fields in the Rapido request formCurrently, there is no option for customers to set fields in the Rapido request form as mandatory (mark them with a red asterix, form can only be sent when field is not empty). However, it is not possible for libraries to fulfill requests where certain information is missing (e.g., no page numbers in digitization requests). We would appreciate if customers would become able to set any field in the form as mandatory such as it is already the case in the GetIt request forms in Primo VE.10Exlibris did not have any questions/comments regarding this enhancement.
4
8485RapidoView requests that activated the Borrowing Copyright RuleIn Rapido, we have configured a copyright borrowing rule to prevent unmediated digital requests for more than one request from the same resource by a patron. When the rule is triggered on a new request, the request status is set to Pending Approval. For staff to decide whether to approve or cancel the request, they need to be able to see the previous request/s from the patron that activated the Borrowing Copyright Rule. Currently, they must search across all borrowing requests and determine which request activated the rule. This can be a time-consuming process. We would like an easy way to see the request/s that activated the rule. For example, the Pending Approval status could be hyperlinked, and when clicked on, the triggering requests display alongside the new request.
On the patron side, we would like Primo to alert them that their request requires mediation. The alert could also take them to their request history in Primo and filter to the previously submitted requests that triggered the mediation. This would be beneficial in scenarios where they have placed a duplicate request, and they could potentially download the previously supplied request immediately.
20Points were determined based on having a hyperlink to view the requests activating the copyright rule, and sending a letter to the patron once we have the information that the request is pending approval due to copyright restrictions or adding an indication in the patron library card in Primo when the request is pending approval.
5
8487RapidILLAbility to query RapidILL lending library from AlmaSometimes we need to contact the library that supplied a RapidILL request to query the copy they provided. For example, supplementary material that was requested was not included, or the incorrect article/chapter was uploaded and sent to our user. At the moment, we need to find out the institution and send them an email. It would be much more efficient if we could query the 'completed' request via Alma to the Library. This functionality should update the request status and record the communication with the request.

There is a Resupply request feature included in Rapido but is not currently possible within Alma Resource Sharing, so a similar solution would be useful.
10
6
8494RapidILL/Rapido/ALMA RSAlma/Rapido notes: Reason for rejection should be passed on through RapidILLCurrently, the only notes passed on in a RapidILL-Alma integration are notes given as part of the Bad Citation workflow. When a lender rejects a Rapid request via ALMA, they can choose various reasons, such as in use on loan, lacks copyright compliance, etc. These rejection reasons do not currently show up on the Borrowing Request. Borrowing libraries need to be able to notify patrons with the reason their request was rejected. We propose that reasons for rejection are carried over into the notes of the Borrowing requests in ALMA.8Note from Exlibris regarding this request: we can potentially develop support for sharing the lender's "reasons for no" with the borrower. This can be supported both with internal products (Rapido, Alma, RapidILL web page), and through the RapidILL API for Clio, ILLiad, Koha, Relais, Tipasa. Please be aware, however, that those vendors would also need to support this in those systems which would require development on their end.
7
8501RapidILLSupport issue and article-level linkingRapid should support issue-level requesting. We would love our lending requests to come in with accurate issue level data.
When RAPID provides a link to owned/licensed material for a document delivery request, we get journal-level data. But, it would be ideal if the link generated were for article-level links through the link resolver.
When ILLiad performs the Rapid Holdings Lookup, Rapid returns a URL. Example of how the URL is formatted: http://rapid.exlibrisgroup.com/redirect?hash=NkM1MjZCMkExQzcxMTQxNDcwRUVCNTU5M0Y4RTJCNDk=

The URL directs to the journal's landing page, not the article being requested. So, I am asking that RapidILL return article-level links for resources when a holdings lookup is performed. \n

User story:
As an institution using RapidILL's ILLiad integration, I want to receive article-level links to resources that Rapid has identified in our electronic holdings, so that staff spend less time searching electronic holdings and so that students are able to deliver requests without intervention from full-time staff.

Related, we use 360 Link, also owned by Ex Libris, so perhaps there is an opportunity for cross-walking these products?
20This estimation is based on the following understanding: This enhancement would be limited to those that are using 360 Link. Support for other linking is outside of the timeframe of the NERs cycle.
8
8512Rapido/RapidILL/ALMA RSAlma Borrowing Request NoteThe Alma Borrowing Request Note should appear on all Rapid Lending requests: Rapid interface, Alma ISO and all other platforms. User Case: Israeli libraries submit Borrowing requests to RapidILL via Alma. However, the Request Notes (as submitted by our patrons) are not carried over to RapidILL, or to other systems, such as ILLiad or Tipasa. These Notes frequently include important information such as the necessity of Figures / Plates / EndNotes that could help a Lender accurately and successfully fill the request. As a work around, we add them to the Pages field or the Article Title field (which have a limited number of characters). Proposed Solution: We would like to see the "Borrowing Request Note" field in the "Request Attributes section" carry over to the RapidILL request. We suggest that these Notes appear in the Lender Tasks List on the lending side. Request notes should also be imported from other ILL systems into RapidILL and exported in kind.Currently waiting for complexity points
9
8513RapidoRapido to parse all volume formats for multivolume worksCurrently, when requesting volumes of multivolume works, the Rapido tile can only parse the following volume formats from the item description:

"3" (digits only)
"v.3" (no space)
"v. 3" (with space)

This affects the Refine Offer function: if the patron inputs a string that Rapido cannot parse (for example, "XII", "Jan", "Bd. 3" as written in the item description), it disregards that volume information. This usually gives a positive result (terms are displayed disregarding the volume's availability), places the request on title level (whole multivolume work) without linking the wanted volume (item) to the Rapido request. In such cases, the availability displayed by the Rapido offer is not entirely reliable, as the system does not identify the correct volume (item) but placed the request on the whole title (whole multivolume).

For example, if the volumes' sequence is "Bd. 1", "Bd. 2", etc. - entering only "1" works. But entering the string "Bd. 1" does not, and ends up in placing a request on the whole title (Rapido cannot parse the "Bd." string).\n

Another example is for Multivolume works that do not have a digital sequence, but only with letters (A, B, C...), or even text ("Textbook"...). Rapido cannot parse these information so the request will always be placed on the whole title, disregarding the availability of the volumes.\n
In such case, the patron can even send the request entering a volume that does not exist if the string contains an unrecognised format.\n

We would like Rapido to consider other formats. For example with an "intuitive" parsing (e.g. as much "Bd. 3" as "Textbook", or "Vol. 3", "Volume 3", "A", Roman Numerals “I” etc.), or by displaying a dropdown menu with options based on what is filled in the items’ description.\n
1515 complexity points will provide an additional 5 parsing options. For reference, each text will be considered one parsing option, regardless of the numbers after the text. For example: Bd. 1, Bd. 2, Bd. 3 will be considered as one parsing, while Band 1, Band 2, and Band 3 will be considered as the second.Ideas Exchange: https://ideas.exlibrisgroup.com/forums/935112-rapido/suggestions/46786285-rapido-to-parse-all-volume-formats-for-multivolume
10
8518RapidoPossibility to re-loan an item after the max. renewals possible at the pick-up libraryWe would like to have a parameterization option that allows the following: Items requested with Rapido that have reached the maximum renewal possibilities can be re-loaned at the pick-up library without having to be returned to the owning library if there is no other reservation on that specific item. That means: Rapido should check if there is a reservation on that specific item. If yes, Rapido sends a warning message. This creates unnecessary inconvenience for users and the restriction doesn't exist in Alma RS. Increasing number of pod renewals is not a suitable solution in this scenario, we need to be able to manually override the limit when required. It would be particularly useful for an institution using Rapido to fulfil postal delivery/courier requests.

See also the voting in Idea Exchange: https://ideas.exlibrisgroup.com/forums/935112-rapido/suggestions/46854874-possibility-to-re-loan-an-item-after-the-max-rene
25Solution provided: A new action will be created on the borrowing request for a pod that was opted-in. Once the library staff activates the action, Rapido will verify that there are no reservations for the RS item at the lender, and in case there aren’t, Rapido will complete the request on both borrower and lender's side and recreate a new borrowing request and a corresponding lending request that will be in the same status as the previous requests. In addition, the loan attached to the previous request will be returned, and a new loan will be created for the patron and attached to the new borrowing request. This workflow will be automated.
11
8530RapidILLPrevent multiple requests from a same borrowing library within a short period of timeWithin a same day, we sometimes receive (in Alma) several RapidILL requests coming from a same institution for a same book or journal issue (native electronic materials or scans from physical materials): usually one request per book chapter, one request per article, etc., but sometimes, some of these requests are for multiple chapters or significant portions of a work. We assume that in most cases, these multiple requests come from a same requester, associated to the borrowing library.

In addition to copyright issues that multiple request raise, it is unreasonable to expect a lending library to expend spending a lot of time to scan significant portions of a work.\n

We don’t expect any systematic mediation from borrowing libraries. This would increase the turnaround time, make the process heavier and slower for end-users and be in contradiction with encouraged integrations like Alma/RapidILL and Alma/Rapido. Instead, we would like lending libraries to have the possibility to limit the number of requests they receive from a same borrowing library for a same book or journal issue within a given (short) period of time.

Example of configuration: “Maximum XX requests in YY hours for a same book or journal issue from a same borrowing library”, where ‘XX’ and ‘YY’ would be numeric values to select from a drop-down list.

Possible values for XX and YY should be defined in collaboration with the RapidILL and Rapido WGs.

In case the values for XX or YY would be reached:
1) Any new request matching the limits should be assigned to another lending institution that owns the requested material.
2) The borrowing library should be informed that there is a risk of multiple requests from a same requester. The library could reach the requester, explain the resulting copyright issues and/or decide if possible to acquire the highly demanded material.\n
3) If no other library can provide the material, request should be cancelled and associated with a new ‘Request Cancellation Reason’ code in Alma. It is important that Resource Sharing requests that would be cancelled for such reasons explain the requester that requesting a too large part of a journal issue or book is not without consequences or risks.\n
201) Any new request matching the limits should be assigned to another lending institution that owns the requested material.
We can develop lender configurations to support this.

2) The borrowing library should be informed that there is a risk of multiple requests from a same requester. The library could reach the requester, explain the resulting copyright issues and/or decide if possible to acquire the highly demanded material.\n
This is beyond the scope of RapidILL functionality and should be part of the borrower's workflow in their local ILL management platform.

3) If no other library can provide the material, request should be cancelled and associated with a new 'Request Cancellation Reason' code in Alma. It is important that Resource Sharing requests that would be cancelled for such reasons explain the requester that requesting a too large part of a journal issue or book is not without consequences or risks.
Due to current limitations in the RapidILL infrastructure, we do not have the ability to develop this within the NERS timeframe.
We can assign complexity points for this Request based on #1 above, excluding #2 and #3. Please check with the submitter to see if this is acceptable.
Exists also as an idea on IE: https://ideas.exlibrisgroup.com/forums/935109-rapidill/suggestions/46946176-prevent-multiple-requests-from-a-same-borrowing-li
12
8533RapidoRapido Closing Periods: Due Dates & RenewalsWe noticed that Rapido does not consider closing periods entered in the calendar of the library. The due dates of Rapido requests are therefore not based on that calendar, while the due date of the loaned temporary item is. Consequently, a mismatch occurs, which in addition interferes with the renewals.

We would like that:
- Rapido considers the closing periods entered in the library calendar in Alma.
- Rapido synchronises the borrowing and lending requests due dates.
30Solution provided: Once a borrower receives the book and loans it to the patron, Rapido will now use the Closed Library Due Date Management to determine the loan due date based on the library's policies. If the Due Date is affected, Rapido will calculate the new borrower's due date and notify the lender. Rapido has no support to change the lender's due date from the borrower, so a new message should be created to support this workflow and automatically change the due date at the lending library. The workflow will be done on Pods that will opt-in for this behavior.
13
8534RapidoUser identifier should be visible in requests for the lending library (for both Rapido and RapidILL)Rapido/Consortia request: Some libraries would like to have the ability to share patron information with the lending libraries. Although, this is atypical in a traditional interlibrary loan approach due to privacy regulations, it would make sense for those using Rapido for consortial loans. We propose that libraries are able to OPT IN to sharing patron information (identifier/name/email) through a Rapido Resource Sharing Configuration setting. This enhancement would be integral for consortia with Network Zones, where lending libraries are forced to enquire for information from borrowing libraries on reciprocal end-users. User Case: We have 490 libraries in our consortia and we use restricted PODs that are limited to libraries within the consortia. It is important for both, physical and digital because with both formats libraries reported often needing to request for more information from patrons and patron information is shared across the entire country but Rapido hides it for the lending library.13Complexity points reflect the basic development of moving the primary ID from the borrower to the lender note field without the option of getting the patron's information and presenting it to the lender. This would be an opt-in feature defined at pod level due to the user privacy aspect.
14
8539Rapido/RapidILLReservations can be placed for digitization requests (RapidILL)When a physical item is already on loan with a first patron, and a second patron wants to request the digitization of that same item, there should be an option to reserve the item for the second patron, so that when the physical item is returned by the first patron, it can immediately be scanned and sent to the second patron.45Solution provided: To support this workflow, development should be done on both RapidILL and Rapido, and integration needs to be done between the two systems. We need to change how RapidILL works now because there are no availability checks in Rapid. Currently, Rapid will look if an institution holds the resource, and if it finds one, Rapid sends the request to it. We will need to add functionality that will check if an item is available or not based on the pod’s reservation configuration and send an indication to Rapido that the item is not available so Rapido can give the patron an indication that a reservation can be placed for the request. Rapid should also support more than 24-hour limits to fulfill the request in these cases.

Voting for this request would only leave 5 development points.
15
8558RapidILLAdd “Conditional” to RapidILLSometimes libraries need to communicate things to each other that aren’t citation issues. For instance, if a library has an HTML version of an article instead of a PDF with page numbers or a different edition of a book than the one listed in the request, that library might want to ask the borrower if that’s an okay version for the patron. Right now the only way to communicate between libraries is through Bad Citation, and that doesn’t allow libraries to respond to such queries. Adding a “Conditional” status that allows libraries to ask and answer questions that aren’t citation problems would help patrons get the items they need instead of requiring libraries to guess at whether what they have is sufficient.8From Exlibris: Supporting a full conditional workflow in RapidILL, which would require new request states, routing enhancements, and significant development by other vendors, is very complicated and outside of the scope of the NERS timeline/process. Proposed Development: Create a new Rapido action which will provide the ability to send an email to a partner library directly from within Rapido. The email will then be stored in the Rapido borrowing/lending request for later reference.Please see the complexity notes for details on what the available solution is for this ask.
16
8562RapidoResource sharing form: Pickup location field should only show on physical resource sharing requestsUsers should not have to choose a pickup location for articles/book chapters that will be emailed to them.
Current problem: In order to mandate users to fill out the field “pickup location” for physical resource sharing requests, we have to also require patrons to fill that field out for article and book chapter requests, which will be delivered digitally. We're running all digitization requests through the Rapido digital offer tile, not the Digitization function in Alma. The goal is to cut down on the amount of buttons/options our users have to choose from. The pickup location field is in the Resource Sharing Request form (Alma Config > Discovery > Resource Sharing Request). The problem is that this Resource Sharing Request form isn't smart enough to tell between a physical and a digital request. The "Pickup Location" field is in the "Delivery Fields" section, which applies to every request, regardless of format. In order to mandate our users to pick their preferred pickup location for physical requests, we have no other option than requiring them to fill out this form for article/book chapter requests too.

This is an issue for multi-branch libraries who do not assign primary campuses to their patrons. As a large community college whose patrons take classes at multiple campuses, we do not have a way to assign a default pickup location in our user records. We are likely in the minority with this setup where our users can swirl between libraries and are not automatically tied to one campus, but this is a real pain point for us.

Impact: Users will not have to select a pickup location for requests that will be delivered digitally. This will reduce confusion.
11From ExLibris: We understand that the requirement is to give the option to the institution to remove the pickup location from the digital blank form while showing it in the physical blank form. This enhancement will be developed with the understanding that if the request is changed to physical at some point, Rapido will NOT be expected to calculate a new pickup location.
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100