We are disappointed with the technical support service provided by Ex Libris. We strongly believe that Ex Libris should provide customers with more effective, prompt and interactive service.

There should be an option to call or chat online in real time with a support person who has a sound understanding of the product in question. This would be in line with all system vendors we have previously dealt with.

We appreciate that there will be some issues that are designated as bugs or enhancements and will require more in depth investigation. However, a direct call/chat option with a properly trained support analyst would quickly and efficiently separate these issues from more general product queries. We are aware that there are many call-logging options used widely by other companies, such as FastCall, TenFold and RingDNA, which can be used to allow customer calls/chats to be registered directly in Salesforce. We believe that Ex Libris should implement this improvement as soon as possible.

Please vote to show your support for this idea and feel free to add comments relating to your experience of this issue.

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.

Provide ability to turn off Related Record functionality for physical items. I would like to be able to decide for each related field in the MARC record - 773, 774, 777, 786, 800, 810, 811, and 830 whether or not Primo will display the related record information for physical items.

There are cases where displaying related record information to the user is more confusing then helpful. 830 series fields, for example, will display "related" records that may not relate at all to a users search, especially if the series is general like: "Brill's studies in intellectual history." I would like to have the ability to decide whether or not to display these relations in the user interface.

My libraries circulate various pieces of equipment from microphones, to musical instruments, to 3D printers, to lockers, and the current physical material type table does not suffice without adding a slew of item policies or location codes, which is messy and makes the resulting analytics more painful than it should be.

Ex Libris support states that "The [physical material type] codes cannot be changed, because Development needs them for statistics across libraries." However individual libraries will have items that they need to distinguish between either for fulfillment rule purposes or our own statistics.

I would like there to be about 15 generic material types added to this table that will allow libraries a bit of flexibility in dealing with this category. Similar to how Primo has blank PNX fields that can be used to create additional facets, etc. that best fit the needs of the library and its users.

Request for Alma item barcode be included in the data that is published to Primo as part of the Alma publishing functionality to enable barcode searchability in the Primo keyword search. We have discovered that items migrated from our previous ILS do contain the item barcode(s) in the MARC 945 $$i and is written to the search:general field of the PNX. As such, those items are keyword searchable via their barcode in Primo. However, for items created in Alma, the item barcode is not written to the bib record and is therefore not searchable in Primo. Adding the item barcode manually to the bib 945$$i for each item as part of our processing is not a viable alternative.

We would like an enhancement to Alma publishing that would add the item barcode to the data published in the "AVA" field. This functionality would improve workflow for staff when they need to search a record in Primo without having to navigate out of the items screen in Alma to retrieve the OCLC number, the MMSID or the ISBN, or to pull up the record in Primo when the book is in-hand without needing to key in the title or ISBN.

Examples of migrated records with the item barcode in the 945 $$i:
http://alliance-primo.hosted.exlibrisgroup.com/CC:cc_alma:CP71153242760001
http://alliance-primo.hosted.exlibrisgroup.com/CC:cc_alma:CP71188416360001451

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

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.)

Acquisition librarians want to extend the current "interested users" functionality in order to serve the end user in a better and faster way. The current "interested users" functionality is not sufficient enough, to become useful and really benefit from this functionality we would like to extend it with:
• The ability to sort the interested user list.
Use case: some users (e.g. academic staff) have priority and should get the issue first!
• Make it possible to create hold requests on these items regardless of the existing fulfillment policy:
Use case: some libraries don't allow requests for available items, but this means they're not able to request items for interested users during receiving. (Apparently in the beginning of going live with Alma this was possible...).
• Make it possible to automatically loan the issue to the first interested user when receiving! This way limited routing functionality is made possible for (print) journal subscriptions.

We'd want to be able to control the anonymisation of requests, resource sharing requests and fines and fees in a similar way to loans. In particular we'd like to be able to set a parameter for days since user expiry and since the request or fine was complete.

This would allow us to create a clear policy for anonymising and purging data in Alma so that all data was treated in the same way i.e. could say that all data was anonymised or purged X number of years after user left. It would also allow us to be confident that we are only anonymising data that we no longer need.

Sometimes providers change a journal’s publication frequency throughout the year. So, the prediction’s pattern selected / elaborated at the beginning of the year doesn’t work anymore in Alma. One part of predictions (date of receipt) will be ok until the change but all other predicted items will be false. Now, we can revise the prediction during the year but we must erase the items already received. We can also leave the prediction defined at the beginning of the year and edit manually the false items from the time of the prediction change.

It would save a lot of time if Alma could change the description (number, date, …) only for the items that are impacted by a new publication during the year. We would just have to fill the « Next prediction item’s information » with the new frequency.
This enhancement would save a lot of time to catalogers.

We would like to be able to copy multiple lines from MARC records and paste them into the metadata editor so that multiple MARC fields are pasted into the record in one action. This would help us enormously with our workflow of importing MARC authority records from LibrariesAustralia into Alma.

For us, this is necessary because the LibrariesAustralia headings are not in the community zone and are unlikely to ever be included there and Alma does not allow for Z39.50 import of authority headings.

We have this functionality of copying and pasting multiple fields in the LibrariesAustralia Cataloguing Client and other library systems allow it. At the moment we need to paste each line one by one into Alma and it is slow and repetitive. This process is a step backward from previous functionality.

When receiving Resource Sharing Borrowing items, the 'Automatically Print Slip' option is only remembered for the current session, which leaves this vital function open to error.

This could be improved in one of the following ways (in order of preference):

Option 1: Provide a configuration option in one of the code tables to set the default (this would also be desireable for all similar functions elsewhere, such as in RS Lending).

Option 2: Make the last selected option persist across sessions so our staff can set it once and not have to remember to set it every time.

Option 3: Change the default setting to 'Yes'. (This was done for RS Lending back in 2016 under Idea 'Change default of Automatic Print Slip from No to Yes in Alma RS'). This is the least preferred option as it may disrupt other institutions workflows.

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".

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.