Cancelled by staff status is used any time staff manually cancel a request, but also anytime the System cancels a request automatically and this aspect of the behavior cannot be changed.

1. To assign a different status to a request if the library is able to fulfill the request outside of Alma or in other cases where staff would like to change the status (e.g. a patron has returned the item at the borrowing library but would like to renew it before it is returned to the lender), a lending or borrowing library can reactivate the request. When reactivating the request on the borrowing side, the status of the request will be changed to "Reactivated". The lending library will not see this update and will need to use the "Reactivate" option on their side as well.

Reactivate the Borrowing Request, then manually cancel it again but choose a Cancel Reason when you do.

The "Reactivate" step can be used for resource sharing requests that have been completed, canceled, or rejected. It is available when the request is in one of the final statuses, and the requester exists. Additionally, if an active partner exists, it should have the "Reactivated" step in the workflow profile. The privilege to reactivate requests is based on user role privileges, and it must be enabled in the borrowing workflow profile.

Reactivation is an option for requests that have been completed or shipped digitally. This process involves reactivating the request, editing it, and then closing it again, although it may affect other aspects of the request. When reactivating, options such as "Reactivate loan" and "Send general message" appear, allowing the request to reset its status and return to the proper workflow step.

How to reactivate closed or canceled resource sharing requests

For a sample workflow for reactivating requests, please see: Draft Staff Workflow Instructions | Reactivating a request

• Reactivate is currently part of the Page 1+ Borrowing Workflow but not the Page 1+ Lending Workflow. OCLS can add this step to the Page 1+ Lending Workflow in the NZ.

2. However, it is not possible to manually assign some statuses (e.g. externally obtained) to requests that are automatically cancelled by the system, because their use and functionality is hard-coded and cannot be changed.

Resource Sharing Statuses are actually quite rigid in their application and cannot just be freely applied to any request. When changing the status of a RS Request, the system will not let you select any status and just apply it. Rather, the system is very restrictive on what statuses can be applied, depending on the current status of the request. This is done as a safeguard, to prevent irreparably "breaking" the workflow between the Borrowing and Lending side.

If you attempt to reactivate a request and change the status to one that would break the workflow, you will see a Changed 0 of 1 Request message and the status will not change.

Explanation of what some of the statuses we considered to replace Cancelled by Staff mean:

• Request Completed: this completes the request. Functionally, this just marks the request as Inactive, and can be deleted by the RS Completed Request Cleanup Job (if that job is activated/scheduled). No other differences from the Cancelled status.

• Externally Obtained: this is related to the CCC GetItNow Resource service.

• Received - Not for Loan: This status is primarily for 'Physical non-returnable' requests. The easiest example is a photocopy - a customer wants a partial digitization of a book chapter, but rather than sending this as a PDF or other digital file, a physical photocopy is sent instead. So the request still has to go through the Shipping and Receiving process - you still have to manually mail the photocopy after all - but once the photocopy is Received, there's no actual loan involved. Thus, Received - Not for Loan. This status is also used with a Physical request if there is a TOU/Due Date conflict with the Received item. The most common source of this is if the RS Library does not have Opening Hours configured. Without Opening Hours, a proper due date cannot be calculated, so no loan can actually be created. That will result in this status being used.

For more information on manually adding borrowing requests:

Creating a borrowing request:
Creating a Borrowing Request

Managing resource sharing borrowing requests:
Managing Borrowing Requests

3. The descriptions of statuses can be customized by going to Configuration > Fulfillment > Resource Sharing > Borrowing Request Statuses.

The status of borrowing requests is displayed in the user's account in Primo VE, and these statuses can be customized and translated. This customization allows for more user-friendly status descriptions, replacing technical terms like Cancelled by staff with more appropriate labels.

• the Type_6_header label is missing in the Values where labels are to be configured for the Query to Patron Letter

• St Lawrence and Conestoga both noticed this issue with their letters: https://clo-collaboration-spaces.atlassian.net/wiki/x/FoB2Yw

• Ex Libris Development has fixed your issue regarding the query_6 display issue and you should see the fix with the April 2025 release.

• They advised that as a workaround you can fill in the XSL. Instead of '@@Type_6_header@@' you can add any other text.

• Loyalist was unable to search Seneca’s catalogue using their deep search configurations

• the local search profile P_NH_SY was not defined as a search slot in the view configuration for the view that Seneca College provided access to through the Primo VE Deep Search Configuration; the issue was resolved after Seneca adjusted the configurations for their view and search profile

• colleges were unable to send borrowing requests to Seneca

• a trailing space in the Partner information for Seneca, on the Parameters tab, the server information (na02.alma.exlibrisgroup.com) was causing issues with the delivery of ISO messages. Updating that field in the NZ and distributing the update resolved the issue.

• Fleming and Conestoga successfully tested sending borrowing requests and completing the request process with Seneca

Summary of issue from Ex Libris ticket opened by Loyalist College:

We are not part of a consortium, so we are only able to search our institution for titles in Primo.
We are using the Blank ILL form in Primo (testing stage), which sends the borrowing request to Alma.
When the "locate" function is run on the borrowing request in Alma, it does not give a warning message that it is owned by the institution.
When a borrowing request is created manually in Alma, and the "locate" function is run, it does provide a warning message that the title is owned by the institution.

We have two "sending borrowing requests rules" - 1. Do not send request automatically - no input parameters, output parameter = False, and 2. Do not send if owned by institution - input parameters "Self-ownership = True, output parameter = False.

Ex Libris Support resolution of the ticket:

Our development team has confirmed that Alma is currently not designed to provide this functionality on the blank ILL form, so the next step is to pursue this as an enhancement.

We strongly recommend that you pursue this enhancement through the ELUNA Product Working Group enhancement voting process. On a periodic basis the ELUNA Alma Product Working Group does an open call for enhancement suggestions that are voted on by the ELUNA Alma user community and presented to Ex Libris Development. This is the best way to have your enhancement request heard. Please see the article linked below with common Q&A's regarding the IGeLU and ELUNA enhancement process.

Ex Libris has also made available sharing ideas directly with our product managers using the Ex Libris Idea Exchange website (http://ideas.exlibrisgroup.com ). We welcome you to sign in to the site and share your ideas with us . Additional information can find on the website’s FAQ.

Here is the article - Enhancement Process - Common Q&A

• Loyalist College has added "view local resources" as a first step in their managing borrowing requests workflow to address this issue

• Colleges can address this partially through Display Logic Rules that hide the request option for specific resource types and/or limiting their all Ontario Colleges search scope (New_Discovery_Network search profile) to only physical materials (see the sections Control Service Display in Primo VE and Ensure that your Primo VE Discovery view includes a search slot that searches OCLS Libraries in the Project Documentation).

• However, some colleges have noticed that requests can still be placed if patrons access the resource from databases outside of Primo VE, bypassing the DLRs: Re: Humber - Discussion Page | Comment; Page 1+ Study Group Session 86 (at approximately 41 minutes); Resource sharing appearing when clicking on "Check for fulltext" in EBSCO databases. These requests for electronic resources should be automatically cancelled in Alma (Cancelled by staff status) and patrons will receive the Ful Cancel Request letter.

• DLRs that hide the RS Request Link based on Resource Type are based upon the "recordtype" tag in the Control section of the PNX record for a Primo result. The PNX pulls this information from a record's associated bibliographic information. When this is properly populated in a PNX record, you will see this resource type show up at the very top of a Primo page, right above the resources title (e.g. https://app.screencast.com/3JqKPjqEergnB). But this does rely on the PNX being able to pull information from a full bibliographic record. For Network-catalogued resources, as well as CDI records, this is not an issue. However, it can be a problem with OpenURL records.

When users find an article in a database which then redirects them to a Primo page, this redirection from an outside service/database is done using OpenURL protocol. The problem with that is there's no guarantee that the information sent in the OpenURL will contain all of the necessary information for your DLRs to work as expected. If the service/database sends an OpenURL without a proper resource type, there's no way for Primo (the PNX) to properly populate the recordtype tag, and so the DRL cannot be applied.

You can see this using the example URL: https://humber.primo.exlibrisgroup.com/discovery/openurl?institution=01OCLS_HUMB&vid=01OCLS_HUMB:HUMB&date=20240501&issue=2&isbn=&spage=75&title=Critical%20Education&atitle=Connecting%20the%20Dots%20Between%20Extreme%20Ideologies,%20%22Parent%20Choice,%22%20and%20Education%20Privatization%20in%20Alberta%20and%20Canada.&sid=EBSCO:Education%20Research%20Complete:177504579&volume=15&pages=75-83&issn=19204175&au=Ganshorn,%20Heather&genre=article&ID=doi:10.14288%2Fce.v15i2.186885

First, add &displayCTO=true to the end of the URL, and then load the page again. Once you do, you'll see the button to Display CTO. Clicking on this will open a new tab with the CTO information, which will include a PNX section. If you review this section in the above link, you'll see that the recordtype tag has "bibliographic" for a value, which does not match what's configured in the DLR. This means that the RS Request link will appear for this OpenURL-generated record.

Meanwhile, compare that to the same article but if it was discovered via Expanded Search Results when searching directly in Primo: https://humber.primo.exlibrisgroup.com/discovery/fulldisplay?docid=cdi_erudit_primary_1111308ar&context=PC&vid=01OCLS_HUMB:HUMB&lang=en&search_scope=MyInst_and_CI&adaptor=Primo%20Central&tab=Everything&query=any,contains,Connecting%20the%20Dots%20Between%20Extreme%20Ideologies,%20%22Parent%20Choice,%22%20and%20Education%20Privatization%20in%20Alberta%20and%20Canada.&pcAvailability=true

When searched for in Primo, this instead pulls up the CDI record (instead of the OpenURL). Because it's CDI, the PNX can properly apply the record type and the DLR will work as designed. You can see this by adding &showPnx=true to the end of the URL for the CDI record.

In summary: this is an unfortunate situation that can arise when working with Primo records generated via OpenURLs. Primo and the Link Resolver can only work with the information provided in the OpenURL, so if that information is inadequate it can lead to this occasional request that "slip through the cracks."

Alma currently lacks a direct method to prevent Resource Sharing Requests on OpenURL-generated records.

• Ex Libris has recommended a workaround that involves creating a dummy GES/DLR to hide the RS request option for each college:

• Colleges have also chosen to address this by redirecting the requests to their ILL departments to locate the resources with other partners, sending queries or direct e-mails to users, customizations of their RS Request Form, and using Libwizard form (subscription) or Google Forms (free) for ILL requests for these records: see Primo VE settings for Resource Sharing (RS) - best practices?; https://clo-collaboration-spaces.atlassian.net/wiki/x/AYAUWw ; Resource sharing appearing when clicking on "Check for fulltext" in EBSCO databases; Add a Libwizard ILL form to the Primo VE full record (can also add a Google Form instead of Libwizard)

• adding CSS code for in links to the customization package is another potential solution that could be explored

• Loyalist College has been testing disabling Cancel Request on Locate Failure in their borrowing setup because it was sending the request cancellation letter very quickly to patrons and Loyalist is not ready to disable the Ful Cancel Request letter

• They found that:

  • Borrowing requests with a 'locate failed' status remained in their active borrowing requests and they could review and place the request externally. The Requester does not receive a Request cancelled letter. They are satisfied with this functionality.

  • However, the request with "locate failed" status was only showing a "View" option and Cancel is not available in the row action menu.  Staff can click on the specific request and select "change status" under the ellipsis (...) action menu. It allows them to select "change status" and "Cancelled by staff > Reason: Failed to locate potential suppliers".  However, the job does not make any changes (0 or 1 changes applied).

  • They can also "remove the request" and monitor the "failed to locate" requests in analytics.

Issue was resolved: Loyalist was able to cancel a few "locate failed" requests and is happy with this setting for Loyalist.

• See: https://clo-collaboration-spaces.atlassian.net/wiki/x/AQAVXw

Managing Borrowing Requests

• staff at Northern College were unable to select pickup location and submit form in Alma

• issue was resolved by attaching libraries to their respective campuses in Alma

• the Page 1+ Borrowing Rule and TOU are configured with a Pickup Location Policy of "in patron's affiliated Campus."

• staff member at Cambrian College was unable to see resource sharing request option in Primo VE records, blank form gives a “This form cannot be displayed” error message: this was caused by staff member exceeding 5 active resource sharing request limit in Page 1+ Borrowing Rule

For more information on associate the library with the campus, please see Ex Libris Documentation on Configuring Campuses.

• Niagara College was unable to submit a Resource Sharing Borrowing Request form in Alma without filling out the Request Costs portion.

• The issue was resolved by changing the value in their Request Cost TOU Policy from 0 to "None". Since the policy was configured to have a value (even though that value is 0), it means that Alma is expecting a value in the RS form when it is created. If None is selected, it circumvents this entirely.

In order to facilitate a no recalls policy when a physical item request is placed for an item that has been loaned through a resource sharing request, the Recalled by Partner and Borrower Recall steps have been disabled in the Page 1+ Borrowing and Page 1+ Lending Workflows distributed from the Network Zone. With these steps removed from the workflow profiles, all behavior will be dictated by the normal operation of TOUs and the Loan Recall Configuration menu, as with any other kind of loan. In testing, we noticed that removing these steps from the workflow profiles preserves the due date for the item. However, renewals for the item could be blocked and the status of the item might not be changed in the borrowing or lending requests lists. Staff will be able to see the status in the history of the request.  

Alma is not currently able to accommodate for the delay between when a request is placed and when it is loaned to the patron (how long an item may spend on the hold shelf and in transit) automatically.

Members of the RSWG were able to come up with a work around. We are recommending two steps in the work around for the resource sharing loan lengths being too short:

1. if you changed the delivery delay in each partner profile to 7, please return the value to 0. Initially this step showed promise. However, it seems there was a change in the July update that makes the problem worse.

2. be aware that we have made a change to the Page 1+ Lending Resource Sharing Rule’s attached terms of use “Page 1+Lending Rules.” Lending rule due date (NOT the loan rule due date) has had the value changed from 14 exact days to 21 exact days. If you are not attached to the NZ, you will have to make the change yourself.

This change should result in approximately 14 days for the loan to the patron. Approximate because it will actually be [Lending Due Date]-[Shipping Time]-[Hold Shelf Time]=[Loan Due Date].

We have proposed an idea on the idea exchange to prefer the loan due date length unless it exceeds the lending due date. Please consider voting for the idea. Resource Sharing Loan Due Date

• Presently, institutions outside of the networked environment do not have access to the catalog of networked institutions. In order for an institution outside of the networked environment to have access to the catalog on a networked institution and place resource sharing requests directly from an item record in Primo VE, both institutions will need to implement deep search configurations for Primo VE. The deep search functionality is currently limited to one institution/search profile. Alternatively, patrons can place requests through the Blank ILL form in Primo VE.

• Loyalist and Seneca Colleges successfully added an NZ search profile through deep search configurations and tested placing requests using this configuration

• Ex Libris do not foresee any issues with the colleges outside of the network adding the deep search scope configurations for the NZ and using them to search and place requests in Primo VE

• For more information, see: https://clo-collaboration-spaces.atlassian.net/wiki/x/AYBEX ; https://clo-collaboration-spaces.atlassian.net/wiki/x/AQAUXw ; Study Group Session 88: General Question and Answer, Resource Sharing Office Hours ; Resource Sharing – Search Options for Colleges Outside of the Networked Environment – Instructions

• when the Page 1+ rules distributed from the NZ are edited in an IZ they become managed in the IZ

• for the Page 1+ rules distributed from the NZ appear in your IZ again, you will need to rename the edited rules

• see https://clo-collaboration-spaces.atlassian.net/wiki/x/DwDxWQ

All Colleges MUST add code to the Resource Sharing Shipping Slip letter. Currently there is a coding error that excludes Address Line 3 from displaying in your own shipping slip. This means that you may not print out the street address of your partner.  This is not a contact issue for your partner, it is an issue with your letter. This has been reported to Ex Libris to resolve, but they have not fixed it yet. All environments are experiencing this and will need to modify their code. Address Line 3 is missing altogether.

Open

Here is how to solve it:

1. Go to Configuration > General > Letters Configuration

2. Seach for Name: Resource Sharing Shipping Slip letter

3. Select Edit from the more options (…) menu beside the letter

4. Scroll down the XSL script to the section for:

notification_data/partner_shipping_info_list/partner_shipping_info">

5. Add this row:

   <tr><td><xsl:value-of select="address3"/></td></tr>

Open

• The rs_hold_shelf_expiration parameter, in combination with the ignore_lender_due_date parameter, determine how hold shelf expiration is calculated for items received for resource sharing borrowing requests. This parameter is not managed in the Network Zone.

• If your parameter is set to due_date, the hold shelf expiry time will match the request due date. If it is set to circ_desk, the expiration date will match the hold shelf configuration for the circulation desk.

• Instructions have been added to the Documentation for how to customize this parameter.

• To ensure that move requests show up in the Pick from Shelf list of the library that owns the item, set the rs_auto_request_lending parameter to false and the Show in Pick from Shelf list setting in the Resource Sharing Request Rule in your Request Pickup Configuration to True.

• Instructions have been added to the Documentation for how to make these changes.

• Lending requests only appear on the Tasks widget when they require intervention, with active notes attached. Requests with a New request status do not appear on the widget.

• optional configuration to have new lending requests appear on your Tasks widget without active notes as new requests that require manual intervention by customizing the value of the rs_auto_request_lending parameter added to Documentation

• Internal mapping table updated to exclude resource sharing requests from restore job for colleges in the networked environment

• Ex Libris can also enable this in the IZs of colleges outside of the networked environment, please let OCLS know if you would like us to open a ticket and/or if you need more information

• ‘SUBMIT_PURCHASE_REQUEST_RS' is now enabled for Fulfillment Services Operator / Fulfillment Services Manager roles for colleges in the networked environment

• Ex Libris can also enable this in the IZs of colleges outside of the networked environment, please let OCLS know if you would like us to open a ticket and/or if you need more information

• Previously, when borrowing institution marked an item as lost, the request was changed to lost communicated and no fines and fees were applied to the lost loan. The lender received a message regarding the lost item, and they had to manually send a message with the fines and fees that would be applied to the borrowing institution. The borrowing institution had to manually add the fines and fees to the patron.

• rs_use_tou_for_lost_item parameter was enabled in the NZ so fines and fees will be added automatically to the patron, based on the borrowing library’s Loan TOU

• Note: if the lender would like a lost item replacement cost other than the default applied, they will need to send a note/communication to the borrowing library and the borrowing library will need to add this cost to the item record as a lost item replacement cost when they receive the item

• Instructions were added to Documentation for creating Loan TOU for resource sharing requests

• La Cite College was interested in limiting the pickup location options in their form to the one library working with resource sharing requests

• There is no direct method to achieve what La Cite is asking for. It can be done, but it would require either a) changing the Deliver To relationships between the RS library and the other libraries (not an ideal situation), or b) removing the Hold Shelves from the other libraries (definitely not a realistic option). Or, worded another way, the only way to remove those libraries from the Pickup Location dropdown is to make them ineligible pickup locations; there's no other way to customize the contents of these dropdown menus.

• Alternatively, if the desired outcome is that all incoming RS requests will only be sent to the RS Library's default pickup location, then the simplest solution might be to remove the Pickup Location field from La Cite's RS form. Since a default location is configured, all incoming RS requests will be routed to this location unless a user configured the dropdown menu otherwise. So if the menu is not visible (and a user can't edit it), then every request will use that default pickup location.

• Configuration>Discovery>Display Configuration>Labels>Request options Labels: https://clo-collaboration-spaces.atlassian.net/wiki/x/AYAUWw

• French label translations created by University of Ottawa for OCUL:

• Instructions to be added to Documentation