RapidILL
Your feedback matters to us. Help us improve RapidILL by telling us what you’d like to see using the message areas below. You can also can support something already posted.
We would love to be able to respond to every idea that is submitted, but this is not feasible. We are, however, committed to responding to the most popular ideas—those that have received the most points.
For more information please review our FAQ and guidelines. Thank you.
26 results found
-
Electronic holdings should take priority over physical holdings
Currently, the format is not a parameter of the algorithm used to select the most appropriate partner. Electronic holdings should take priority over physical holdings: this would avoid institutions to digitize print materials (operations that take time and human resources) while others may have an electronic version that can more easily and quickly be provided.
If Partner A has an electronic access and Partner B has a physical holding (and things like time zones being equal), Partner A should receive the lending request in priority.
185 votes -
Alma/Rapido notes: Reason for rejection should be passed on through RapidILL
Currently, the only notes passed on in a RapidILL-Alma integration are notes given as part of the bad citation workflow.
However, as borrowing library, in order to reasonably notify the patron why a request is rejected, the note containing the reason for the rejection by the lending library also needs to be passed on into the borrower's Alma/Rapido.168 votes -
Defining Work Week permanently
It should be possible to define our work week permanently, and not via Lending Off every week. For example, our work week is Sundays-Thursdays 8:00-17:00 (not Monday-Fridays). Also, it should be possible to define Lending Off via Alma, and not just via the Rapid interface.
87 votes -
Prevent multiple requests from a same borrowing library within a short period of time
Within 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…
84 votes -
Reducing turnaround times
Since each lending library can hold a request for 4 working days, sometimes files are received after a long time (for example: if there are many libraries and each one takes 4 days to Unfill, before one library eventually fills it).
A solution to this could be to treat requests with only one match differently than requests with many matches, e.g., reduce the holding time for requests to 2 days when more than 1 library holds the item.79 votes -
updating Lending requests to Filled without sending the file
Sometimes libraries update Lending requests to Filled, but do not actually send the file via RapidX or any other way.
There should be a way to indicate that the file was not actually sent to the Borrowing library.62 votes -
Show dates in a format suitable for global users
In the RapidILL interface dates are displayed in US format. With RapidILL now a global phenomenon this can be confusing for users in other regions which do not use M D Y.
A date like 10/06/2022 - could be interpreted either as 10 Jun 2022, or 6 Oct 2022.
Please use a format like 05 Sep YYYY - that should prevent confusion and make work more efficient outside of North America
48 votes -
Customising Reasons for Rejection
As it stands, we cannot customise the choice of reasons for rejection when we reject a lending request. It would be useful to be able to configure this to make them clearer, and have reasons that we find the most applicable to the type of requests we get. For example, having one that is more applicable to specific copyright restrictions, or when we have an access issue. As well as this, it would be useful to remove reasons we don't use.
47 votes -
ISBN
Currently, when you submit a request with an ISBN, Rapid does not also search for the ISBN of the Ebook, or vice-versa. This is not the case with Journal requests, Rapid does search for alternative ISSNs of print journals and ejournals.
35 votes -
Support issue and article-level linking
Rapid should support issue-level requesting. We would love our lending requests to come in with accurate issue level data.
Related, 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. We use 360 Link, also owned by Ex Libris, so perhaps there is an opportunity for cross-walking these products?
26 votes -
Submitting requests via Alma using DOI
Currently, Rapid accepts requests from Alma with ISSN / ISBN and OCLC number. It should also be possible to submit requests that only have a DOI.
25 votes -
Alma Borrowing Request Note
The Alma Borrowing Request Note should appear on all Rapid Lending requests: Rapid interface, Alma ISO and all other platforms
25 votes -
Rapidill lending requests: Locate item on loan
We often get scan lending requests from Rapidill for items that are on loan. It seems that the Rapid locate mechanism should be improved.
24 votes -
Please allow sites to FTP holdings files to RapidILL. That way we could automate and do on a more frequent basis.
We have two ExLibris products: RapidILL and Summon. It it frustrating to have to use two completely different processes to send holdings records. RapidILL is especially frustrating because it's a web interface and files can't be sent with FTP. (We're a SirsiDynix site - we have a report that can automatically extract and FTP records to a third party site. It works beautifully for Summon.)
21 votes -
Make Holdings Status Page & Upload Process More User-Friendly
Currently, the holdings upload process is a bit of a black box. There are no notifications to tell libraries that our holdings uploads have failed. So, we have to keep checking the Holdings Status page (https://rapid.exlibrisgroup.com/Holdings/Status) to see if our uploads went through, and submit a ticket if they don't. Failed uploads are still marked as “In Progress”. Because of this we have to wait 24-48 hours to establish that the process has stalled and requires intervention. If we notice a failure, Support cannot tell us what caused it because data from past uploads is not retained. A…
18 votes -
Incorporating non-English phrases into holdings upload to Rapid
It should be possible to upload non-English phrases into the Rapid process for parsing years and coverage data.
Our description field is in Hebrew, which means that the data is ignored, when Rapid tries to upload it. As a result, requests are automatically sent to Rapid instead of being rejected as Locally-Owned. This causes unnecessary work for other libraries, and in many case, a delay in supply to the patron.17 votes -
Problem with Hebrew Numerals in Publication Dates and Volumes / Issues numbers
When we submit requests to Rapid that have Publication Dates and / or Volume/Issue Numbers with Hebrew numerals and / or apostrophes, Rapid is not able to identify locally-owned items, or to accurately locate possible Partners.
16 votes -
Add “Conditional” to RapidILL
Sometimes 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…
13 votes -
Allow to fill RapidILL requests with URLs instead of files
When staff users try to use the workflow step "ship digitally" and indicate a URL instead of uploading a PDF, the request is closed at the Lending side but the patron never receives any notification and the Borrowing request stays pending.
After checking with ExLibris, it seems that Rapid/Alma is not currently designed to be able to fill RapidILL requests with URLs (instead of files).
This would be very helpful though, especially in case of large files.(Described also in support case 6645065)
13 votes -
Claims for non-supplied items
Ability to configure non-supplied Alma requests that were sent to Rapid to automatically update to status Claimed
12 votes
- Don't see your idea?