If an user has found an article that is not available electronic, but the library has the journal in print, the end user gets the list of holdings for the journal and can go into a specific holding to see the items.

In general we would like that when the end user has found an article they should only need to click on Request (or Digitize) and all relevant metadata are sent to Alma and the system selects the correct item to fulfill the request. If locate is not possible the librarian has enough information to work on the request.

The end-user are on the article level while the system are on the journal/issue level.

The end-user gets a lot of items and need to find the correct item either using the drop-downs or the navigational buttons. Not very user friendly. Could it be made easier to display the items that might fulfill the request by preselecting based on the metadata in the record?

This sceanrio are described in this screen-recording:
https://cloud.bibsys.no/index.php/s/XWASfMFpqbmFYpK

If there are no items to fulfill the request or the end user gives up finding the right item the Request a different issue option should contain more metadata that is sent to the library. This issue are adressed in this idea:
https://ideas.exlibrisgroup.com/forums/308173-alma/suggestions/36901999-improvements-to-request-form-when-article-is-not-a

I believe this is an expansion on this idea https://ideas.exlibrisgroup.com/forums/308173-alma/suggestions/31119715-title-level-request-and-item-level-request

But we are dealing with ASRS in our case so I thought it might be a little more elaborate.

We would like to have the option to allow each items’ request policy with specific parameters (location, keyword etc.) to be excluded from the title-level request policy.

Currently we have "No requesting" as our general policy that's applied to all of our items except for the ones in ASRS. The problem is that when items with multiple copies and identical call number exist both at open-stack library and ASRS, the No requesting policy takes precedence over everything else even if ASRS items are set as requestable.

It would be beneficial if the patrons are able to choose freely where they want to request from based on the items’ availability instead of having No requesting applied across all locations, especially when the item is actually "requestable" in ASRS.

When the close_paid_lost_loans parameter to false and lost loans are closed (either manually or through the Close Lost Loans job), refunds/credits are not automatically given to patrons if the item is subsequently found and returned. When setting the close_paid_lost_loans parameter to true and the lost loan is closed (automatically setting the Lost and Paid status), a refund/credit IS applied to the patron’s account if the item is subsequently found and returned, providing the Lost Loan Refund Ratio is greater than 0.

For libraries that wish to take advantage of this new Process Type, but do not wish to issue credits automatically for Lost and Paid items, this can cause some problems. Staff must monitor and waive these credits as they often negate other fines on the patron’s account. In addition, the credit can cause problems with automated financial processes (i.e. Bursar integration) as credits transmitted to the financial system can act on non-library fees owed, or create automatic refunds that may or may not be due depending on the refund policies in place.

Proposed solution: When setting the close_paid_lost_loans parameter to true, we’d like an additional option to allow or block the automatic refund/credit when a lost and paid item is found and returned. In other words, we’d like the option to keep the new Lost and Paid Process type, but also the ability to actually close the loan completely as is done with regular Lost Loans.

We use the booking functionality in Alma for our Audio/Video-equipment. The equipment is administrated by our media production department, and is configured as a library in Alma.

The AV-library is the only place on campus patrons can check out and return AV-items. Apart from that, the AV-library also supports delivery to a library at a different campus (Kjeller).

• The transit time between the AV-library and Kjeller is set to 48 hours.
• The preview time on the equipment booking is set to one hour.

Use case:
When scanning an item due for pick-up at Kjeller within the next 48 hours, Alma insists you reshelf the item at the AV-library. Alma keeps on insisting you reshelf the item, until one hour before the booking time, alas until you are within the set preview time. Then, and only then, the item goes into transit to Kjeller, and the workflow is as expected. This of course, results in the equipment being too late for pick up at the Kjeller library.

If we change the preview time to 48 hours to accommodate the transit to Kjeller, the correct workflow kicks in at the expected time and the equipment goes into transit. Unfortunately, this affects the preview time for all the AV-items, regardless of pick up location. One apparent downside being patrons are blocked from checking out booked items, 48 hours prior to the booking time.

Our present work-around is to keep an eye on “Monitor Requests and Item Processes”, in order to sort out the equipment booked for pick up at the Kjeller library. Checking out the item as loaned for the patron before shipping it to Kjeller. The obvious downside, not being able to track the item in process, use scan in item … etc.

Suggested solution:
We would like to be able to make an exception to the preview time for bookings in the Fulfillment Unit based on pick up location: IF pick-up location=Kjeller THEN Preview period=48 hours.

In our previous system, with one click we were able to change items to Claimed Returned status, no matter what their current status was. one click and it was done.
But in Alma, for some reason, this is not possible once the item has been declared Lost. One has to go through a long and convoluted process creating a file and saving it then creating a set and saving it then running a job on the set. This involves three pages of instructional documentation and about 15 minutes of staff time every day.
We often have items claimed returned when they have automatically gone to Lost status, and it would be really useful to have the Claimed returned option appear as a choice in the elipsis also when the item is Lost.

When managing Digitization Requests, there is no control in the last step (when files or URLs are attached) that a file or URL has effectively been attached or correctly uploaded. If operator clicks on 'Done', the request is completed without any alert!
If no file or URL has been attached when the operators clicks on Done, the requester receives a letter with no attachment or URL for download. Waste of time and bad service provided...
There should be a control before clicking on Done, at least one file or one URL should be attached before the request gets completed. At least one uploaded file OR URL should be mandatory.

A few libraries in our consortium have expressed interest in more granularity for "On Hold Shelf Letter" configuration.

In particular, the ability to have this letter dynamically show the ILL sender email address (ILL@institution.edu) for any item with a Resource Sharing (RS) location code. If an item has any other location code, show the Circulation sender email address (circ@institution.edu).

It would be ideal be able to set this type of condition in a rule similar to the way Display Logic Rules work in the Alma Configuration Menu.

Currently the circulation email address is our default and only option for the "addressFrom" field.

The new short_loan_courtesy_reminder & short_loan_overdue_reminder cannot be configured for multiple locations. For institutions with several hourly loan locations (for example Boston College maintains 2 and 3 hour loan periods for Course Reserves and a 4 hour loan period for some technology items) this dictates that the reminder notice has to be set based on the location with the shortest loan period. The overdue notice must be timed to make sense for for the longest loan period.

In our test configuration we used the following time parameters:

​short_loan_courtesy_reminder - 105 minutes
short_loan_overdue_reminder - 241 minutes

However, this creates a situation whereby patrons borrowing from some locations will have already incurred an overdue charge before the overdue notice is sent.

In order for this functionality to provide the service is designed for, it must be robust enough to support different loan periods.

https://knowledge.exlibrisgroup.com/Alma/Product_Documentation/010Alma_Online_Help_(English)/030Fulfillment/080Configuring_Fulfillment/110General#Configuring_Fulfillment_Jobs

I found this idea buried in a comments section and felt it deserved its own idea since my team keeps encountering the same problem.

https://ideas.exlibrisgroup.com/forums/308173-alma/suggestions/11117682-payment-option-on-user-fines-fees-tab

Iain Gray said: "After finding a user it would be useful if when clicking on Manage Fulfillment Activities you were presented with the same screen as though you had used the Manage Patron Services screen. Instead you do not see the option to pay Fines and Fees from here and have to re-enter users details again."

I'll add that it would be great if Manage Patron Services and Manage Fulfillment Activities were the same page and named the same thing. The staff user experience is tedious:

1) Patron comes to desk with scant details about their account,
2) Staff runs a user search in the persistent search,
3) Staff reads out list of checked out items and fines owed,
4) Patron wants to pay fines, and then
5) Staff run a new search in Manage Fulfillment Activities from the “Fulfillment” dropdown.

Re-entering the user details over and over again into different search fields has become a hassle for desk staff, especially here in an academic library at the end of a semester when everyone's trying to settle their debts with us in the same week.

The blocks tab on the User Details screen should display system assigned blocks as well as librarian assigned blocks.

It is confusing for staff if a user is blocked but the block doesn't show on the user details screen, only via Manage Patron Services.

This idea is partly related to "Make Manage Fulfillment Activities the same thing as Manage Patron Services" (https://ideas.exlibrisgroup.com/forums/308173-alma/suggestions/36274744-make-manage-fulfillment-activities-the-same-thing) - one of the ongoing issues with Alma from a staff point of view are the number of different screens things are under, and not in a particularly intuitive way. Waive a fine here, pay a fine there. See a system block here, see a librarian block there. It would be much better if things could be brought together, both day to day for staff and also to make it easier for new staff to learn the system.

Please note: this idea is not ours originally. We voted for this as an institution as part of the first round of NERS 2018, where it was Req ID 5782. I noticed that it isn't in Ideas Exchange now (or at least I don't think so).

Quoting the original description: 'We would like it to be possible to notify users when they have an item on loan that cannot be renewed, and to explain the reason to them so as to avoid confusion to patrons. Reasons may include: - because it is requested, - the patron has reached their expiry period - or the item has reached its maximum renewal period.

Currently when an item is about to go overdue a notification is sent to warn a user that an item must be renewed or returned even if there is a request on the item. However, when a renewal is attempted, whether by the patron, automatically, or by staff, it fails, e.g. because of the request, with no notification of the failure which is confusing to the end user.'

We would like to be able to directly deal with requests in the queue via way of the scan in item screen in Alma. Currently if you scan in an item to satisfy a request, and it's not part of the requesting pool then you cannot satisfy the request - even if the request is for something simple like partial digitization, and you have the item in hand. You also cannot currently satisfy requests in the queue which aren't at the head of the queue - ie ready to process at position 0.

The idea would be that at the scan in item screen, a checkbox could be selected so as to force the item to satisfy the request. It would require the operator to scan in the request ID and candidate item barcode in order to pinpoint the request workflow the item would be rail-roaded into, and then the item would follow the normal workflow until the request was processed, and return back to it's original location.

The functionality should take into account existing checks as to whether the item is missing, already in a workflow, or in any other conditions such as out on loan, that would preclude it from satisfying the request, ie marked as lost.

Our use case in this example would be using items in our high demand collection to satisfy patron digitization requests. Normally high demand items are restricted from being requested, so and so the digitization request could be sitting in the queue for weeks until a physical copy from the main collection can be used to satisfy the request. In this scenario, you would then just scan in the high demand item barcode and the request ID for the digitization request, and work your way through the digitization process until complete, and then the item would go back onto the high demand shelf.