7 results found
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
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
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
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 failure of one holdings upload in a particular file type causes all the others in that file type to fail, even if there’s nothing wrong with the other files. Since Support cannot tell us what caused the failure, we just have to check all the files for potential fail points.
To help libraries remedy holdings upload failures more promptly, so that we can ensure more accurate holdings and a better request experience for our users, I propose the following enhancements to the holdings upload process and Holdings Status page.
1.) Create notifications that will alert libraries when a holdings upload has failed and, ideally, why it has failed.
2.) Implement more granular batching of holdings uploads, so that a failure of one holdings file does not result in a failure of every other file of that type. As we understand it currently, a failure in the print books upload would also cause the electronic books upload to fail, even if there was nothing wrong with the electronic books holdings file.
3.) Provide granularity in the “Last Index Date” field for holdings format and type. Currently, that date only reflects the last index for the entire holdings type. In the current system, if we upload electronic journals on October 5 and print journals on November 9, the Last Index Date will read November 9 for both sets of holdings, even though the electronic journals really have not been indexed since October 5.
4.) Introduce more meaningful and specific status indicators. Mark a failed holdings upload as “Failed,” “Paused,” or the like, not “In Progress”.
5.) Provide more thorough documentation of how to interpret the Holdings Status page. The Knowledge Center documentation is very sparse. We only really understood what was happening behind the scenes after repeated questions to a patient Support rep. (Thanks, Neta!)
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
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
The Search Holdings feature for books is very limited, it doesn't include the Author or Publication Date. Conducting the same search under Borrowing>New Request is inconvenient as there are four required fields.10 votes
Please consider adding could the ability to separate the mapping list between chapter lending and whole book lending. More of our collection is available for chapter scanning than whole book Rapid Returnables lending. For example, we could scan a chapter of a reference book but we would not provide the entire book via Rapid Returnables. We have put in place the more restrictive lending rules as there's no way to distinguish between chapter scanning and whole book lending in the mapping .7 votes
- Don't see your idea?