With an active automatic rota for books, borrowing requests sent from Primo to Alma are automatically sent to partner. This applies for books published within the last year as well. Before we activated the autoROTA, we would usually change most of these borrowing requests into purchase requests and place the patron on a waiting list.
New books requested by a patron are often items we want to purchase ourselves, and not spend money on borrowing from our partners in addition. With the autoRota there is no way for us to block these borrowing requests from being sent.

We would like a Sending Borrowing Request Rule with Input Parameter Publication date = within last year (or 2 year, maybe optional range), and Output Parameter Send Request = False.

The Query to Patron letter functionality for Borrowing Requests in Alma has recently been reimplemented to use the standard mail configuration in Alma. By some reason an exception has been made for the "addressFrom" setting, where it instead still uses the default address for the Resource Sharing library.

This is counter intuitive, as the addressFrom value is still configurable for the letter, only it doesn't have any effect. I'm still surprised my case (#00609529) was identified as a documentation issue and not a bug.

If you like us has selected to not implement a separate Resource Sharing library, this also effectively prevents us from using a separate address for these letters. When switching to the new letter type, this was the feature we most looked forward to ...

Please make this setting take effect for the Query To Patron Letter just like for any other letter.

(If there are use cases where this would make things worse, please consider adding an general option to toggle between the two styles!)

When setting recall period on a fulfillment loan to "No recall due date", the original due date is kept, while renewal of the recalled loan is blocked.

For some reason, a different logic is applied to lending requests. Setting "No recall due date" as the recall period policy for lending requests, results in the due date being set to the date of the recall. The result is unpredictability for the borrower.

We propose that that these two very similar workflows are better alligned and that setting "no recall period" for recall should result in no change to the due date on a recalled lending request.

Audun Skorstad
Unit – The Norwegian Directorate for ICT and Joint Services in Higher Education and Research

When working on resource sharing requests lists (lending and borrowing) the first thing to do is selecting another search entry/term, mainly an aspect at the end of the list, to find a special request, because the author ist never the aspect we search for. The list in the pull down menue is hard coded and there is no option to re-order the list as we need it.
At least we like to achieve that the list starts with the last three search aspects the staff user has used. Alma has to remember them for the logged in staff user similar to the functionality developed for the NUI in connection with other topics (i.e. last location - currently at... or last searches in the persistant search box).
We need this functionality for Resource Sharing Requests as well.

Currently, when a borrowing request item is received, the due date of item is set by the lender's TOU. If the due date falls on a library close date, the due date remains unchanged. This causes the problem when clients are misled by the due date and would visit the library to return the item even though the library is closed. We would like to add in the Closed Library Management policy type to the RS Borrowing TOU so that we can indicate in the event the due date of the RS request falls on a library close date, Alma can change the due date base on the library preferences (similar to the Closed Library Management Policy rule in Loan TOU).

When using Lender Due date for RS items (Fulfillment > General > Other Settings > ignore_lender_due_date = false) the date for Pick up from shelf is the same as the Due date. This is, according to ExLibris, working as intended, but we have a few issues with the workflow.

This makes the workflow more manual and difficult than needed, given that we have to manually check RS items that is not getting picked up by patron within a couple of weeks. Having the RS items on Hold shelf for up to 4-6 weeks is poor use of time - for the patrons, the book and the library.

If we could set a Hold shelf expiry date for RS items that is shorter than Due date, it would make it easier for the circulation desk personal to remind patrons that they have a book waiting. This will give the book more time at use with the patron, and less on the hold shelf. It will shorten the waiting time for other patrons, as the book will be returned earlier to the owning library if it is no longer needed by the patron.

The best would be if this process could be automated, e.g. by TOU policy. (Much like the Hold Shelf Period policy that exist for TOU type Requests.)
If it’s not possible to populate a Hold expiry date automatically, a data field in the receiving RS items pop-ups would be helpful. (Pictures added.)

In the SNLP workflow the partner changes from the own partner code to the partner who ships the request automatically. Therefore most of the requests have the correct partner when the item arrives at the library.
So most of the time there is no need to modify a partner and the staff's attention to this attribute is not as high as it is to other attributes of the request. If we observe this AFTER receiving the item, there is no possibility to do so.
Because we don't know to which partner we have to send back the item after it has been returned by the patron, we now have to missapply other fields of the request to store this information.
Perhaps not all libraries want to allow their staff to do so, so we suggest a new parameter which can be switched off, if it is not needed.