Currently the limit for email attachments when filling digitization requests is 10MB. We would like institutions to be able to choose their own limit that suits their own institutional email policies (e.g. Otago's attachment limit on their email server is 30MB). Other institutions may wish to have a lower limit so it should be possible to set a limit that is appropriate up to a maximum value that can be supported by the Alma email infrastructure. Our staff frequently bump into the 10MB limit which leads to them cancelling digitization requests in Alma and then manually emailing the attachment to the user which is an inefficient use of technology.

Note that this request is different from "Document Delivery - 10 MB Attachment Limit too small" (https://ideas.exlibrisgroup.com/forums/308173-alma/suggestions/35142943-document-delivery-10-mb-attachment-limit-too-sma) which is focused on attachments that are uploaded to Alma and a link sent to the user rather than on email attachments.

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

Currently the library can turn borrowing history on or off, but the choice applies to all users. For privacy reasons, and in order to avoid subpoena situations, we have it off, but some users do want borrowing history on as a convenience, and are not concerned about privacy risk themsleves. Why not allow those users to opt in to borrowing history, and allow the default otherwise to being off?

By the way, this "opt in" approach is how most public libraries in Eastern Massachusetts are set up, so our users expect this level of service from us also.

It is hard to explain that we leave borrowing history off because in our system turning it on exposes all our borrowers to a privacy risk. When users can't make this personal choice and control their own privacy settings at the university the way they can in their local cities and towns, it makes our library and our online system appear very "web 1.0".

We would like desk operators to have the option of selecting from a list of predetermined check out periods for items in certain collections.

Boston College Libraries currently provide approximately 80 laptops to community members, which can be borrowed for a fixed loan period. For many patrons this static loan period is either too short or too long, adding some loan period choices would enable us to easily meet the needs of more patrons.
Currently in Alma, offering a variety of loan periods would require the creation of additional locations and terms of use. Doing so would enable us to move subsets of our inventory to each location, however, this is an inherently a rigid way of inventory control. What we are looking for is a more flexible system that enables our entire laptop inventory to circulate for a variety of loan periods.

The imagined workflow:

1. Patron comes to borrow a laptop.
2. The laptop is loaned in Alma
3. The operator is presented with a dialog box with a series of loan period options (configured at the library level) - for example (4 Hours, 1 Day, 4 Days, 7 Days).
4. The operator asks the patron which loan period meets the need and makes the selection in Alma to complete the loan.

Thank you for considering this request.

More academic libraries are checking out high-traffic electronic items (laptops, Wi-Fi hotspots, etc.) and often have a long list of patrons with holds on these items. It would be useful if we could manage the queue for user holds/reserves more effectively. We should be able to renumber/reposition users in the queue (presently you may only bump someone up to the very top of the queue or profile a priority if users are from different user groups). We should also be able to manage the queue without having the item available; presently that is not possible. We often have 12+ users on a hold list at a time for laptops...and the users are generally all the same user category (students), so the present Alma functionality is just not helpful. If a laptop comes back and needs to be repaired, it is a big deal to manage the hold queue, so the next person in line is not bumped back to the bottom because that item needs repaired. Managing the queue should be a straightforward thing.

Boston College would like to be able to configure Alma so that work orders are auto-created for materials in a designated location when they are placed on loan.

Here is the desired workflow:

1. Item is loaned.
2. At the same time, Alma automatically places a work order on the item.
3. When the item is returned to the managing circulation desk the work order is triggered and the item is routed to the correct work order department for processing.

The purpose of this request is to improve the management of the laptops that Boston College Libraries loan to patrons, and to facilitate the implementation of an online laptop availability tool.

The process for printing Pull Slips has multiple failure points. Suggestion: Use the Print Slip Report as the data source for a mail merged Word document Pull Slip.

Creating email pull slips is too reliant on multiple systems working at all times. All of the required systems (servers, printers, scripts…) are potential failure points. These failure points often require staff from other departments to resolve. When there is a failure at any of the many points, the result is an inability to process Pull Slips through the normal workflows.

Suggestion: (1) Execute Print Slip Report, (2) Open Word document Pull Slip, (3) Insert Merge Fields to the Word documents from the Excel report, (4) Print.

Hi,
We have dedicated librarians working on digitizations, and sometimes the item they have on loan and like to scan is not suitable for the digitzation process (notes, underlining etc).
They would then like to request another item. This request will be rejected in Alma due to policy. An item can not be requested when you already have a an item from the same bib record on loan. They would, of course, like to keep the original item on loan until they have checked if other items are more suitable.

You are able to request if the items have different policy (enable_request_during_loan_for_different_policy value is true in the Customer Parameters Mapping Table), or if the items are differentiated from one another using the description field https://knowledge.exlibrisgroup.com/Alma/Knowledge_Articles/Configuring_Alma_to_Allow_Multiple_Requests_on_A_Title.

This is not the solution for us.

We would like an additional option to these two under Block preferences in Alma:

#24 Item of the same title is already on loan for this patron. Parallel loan is prohibited. Actions= Override by operator
#25 An item of the same title was recently loaned to this patron. Actions= Override by operator

#?? Item of the same title is already on loan for this patron. Request is prohibited. Actions= Override by operator

The Activity Report letter automatically tries to send when “Renew Selected” and “Renew All” are selected in Alma Patron Services. This is problematic for a few reasons:

1. The letter is triggered even when the letter is disabled in Letter Activity configuration. It generates a ‘fail’ message for staff.

2. The letter slows down processes dramatically depending on how many loans are attached to the account.

3. A workaround is to use the letter opt-out functionality, but we'd have to continually update all of our users with the opt-out in order for this to work well for us.

I would like to see this functionality updated so that disabling the letter is enough to not trigger the letter automatically. This functionality should also be fixed so that the letter does not slow down processes when there are many loans attached to an account.

I suggest that if the "not needed by " date is reached then the patron request is cancelled.

The only function of “date not needed by” for patron physical item requests is to prevent items from being put into transit from other locations if the transit cannot be completed by the required date.

However this is not clear to patrons and users ask us why we send Hold available notices when they already indicated a date when they would no longer need the item.

Staff also waste time locating items that Patrons have indicated are no longer needed, only to waste more time when they take the unused item off the Hold shelf when it eventually expires.

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.

For institutions that handle a large number of Patron Physical Item, and other request types dealing with their physical inventory, the Print Slip Report available under Fulfilment>Resource Requests> Pick from Shelf is a crucial workflow tool.

However the report output is inflexible, including columns which are irrelevant to many customers and which require hiding/deletion in Excel formats before being printed for onward process by library staff.

It would be a huge improvement to be able to configure the columns that go into this report to ensure that only the key ones are downloaded for each circulation desk's pick from shelf lists.

NB The Print Slip Report is somewhat unusual in Alma in that most functional areas have Excel downloads of data from the User Interface which can be configured column-by-column, however the Print Slip Report has no User Interface equivalent display which makes the lack of configuration particularly awkward for the workflow - i.e. it is the ONLY place we can access this vital request-by request, holding-by-holding, barcode-level, service information.