Currently, there is no Description field in Patron Services page. Library staffs are not able to immediately recognize which issue, volume, or number is loaned, returned, or requested by a patron at a glance in three tabs at this page.

When circulation desk staff help patron to check or see their loans in Loan tab, Description field is not visible.
Or, if a patron requests different issues under the same title at a time, when he/she comes to circulation desk and wants to pick up his/her requested items, library staff will need to spend more steps to check the Description of each item. This takes too much time when it is busy at circulation desk.

When returning items in Manage Item Returns page, we can clearly identify which issue is returned through Description field, this is helpful.
Please also add Description field into all three tabs in Patron Services page, thank you!

This feature would add the ability to load and export split coverage date ranges for Alma portfolios. Currently, the portfolio loader only allows uploading continuous coverage date ranges. However, in some cases, a journal has split coverage dates. For example, we might have access to a journal from:

1980-1995
1997-present

Currently, there is no way to upload this using the portfolio loader; the portfolio loader will only load one of the date ranges. This means we must do extra manual work to enter these date ranges in the portfolio editor.

Also, the standard portfolio export features in Alma, in cases where a portfolio has split coverage dates, only export the first range. In the above example (coverage from 1980-1995 and then 1997- present), export options (such as "extended export") only export the first range (1980-1995). This creates confusion when performing exports, as the export sheet does not contain accurate date range information. The only way to export split coverage from Alma is to use Analytics.

These improved import and export capabilities should be added for all uploadable date fields and all exportable date fields, including both the current coverage dates that display in Primo and the perpetual access date fields only visible in Alma.

Would it be possible to have a way of deleting physical item requests older then a certain date? Now it's only possible to delete all requests on a title, but that's not very useful.

Highly requested titles on a courses reading list is often not relevant after a certain date, when the course has ended. We sometimes see that old requests, that we haven't been able to fulfill, are causing unnecessary delay in fulfilling requests that are still relevant for the new, active course.

When we had to close the library in spring 2020, we also could see that a lot of requests wouldn't be fulfilled, and the users would not be interested once we opened again. Unfortunately our users are not very good at cancelling their requests, or give us notice that a book is no longer needed, when they get the hold shelf notice.

Having the possibilty to delete requests older then a certain date, will help circulate our books more efficiently.

There are some electronic services and portfolios in the Alma CZ that do not use parser parameters. Instead, they use ISSN or some other element drawn from the MARC metadata to construct their links. However, there is no indication in Alma when a service or portfolio behaves this way. To the Alma user, it looks as if the portfolios must be misconfigured, as they have no parser parameters and no apparent way to link at the title level. This makes troubleshooting linking problems very difficult, and it conceals the actual linking functionality from Alma customers.

To be fully transparent with customers and to enable customers to better troubleshoot linking problems, Ex Libris should add an indication at the service level linking tab (inherited by portfolios) 1) showing when MARC metadata is used instead; and, when this field is selected, 2) either the Parser parameters field or a new field should show which MARC fields are used to construct the links. I will attach an image showing where I think these new indications should appear in the service linking tab (they should also be inherited by portfolios).

An example collection that behaves this way is Akademiai Kiado, CZ Collection ID 611000000000000691

Work orders are useful but often cumbersome and don't work as required. A package of enhancements/fixes would make them much more useful and useable:

• Adding notes when creating work orders in bulk. This would enable having fewer work order types as explanatory notes could be used instead.
• Makes notes more (immediately) visible when scanning in (pop up message?). Again would enable fewer work order types as items could be easily catergorised according to explanatory note upon receipt at managing department.
• Select recall/not recall at work order placement (like pick from shelf), not baked into type (and in selectable in bulk as well as individually).
• Select/override priority level at work order placement (individual and in bulk)/make it easier to manually advance work orders in queue, AND:
Different priority levels for different work order types.
• Allow managing departments to manage multiple work order types (like circulation desks can) - increased versatility and flexibility.
• Where circulation desks (and hopefully managing departments) manage multiple work order types, make it possible to view all in-process items and have work order type immediately visible.
• Alert on scanning into work order managing department if higher priority work order/request exists.
• Enable cancelling specific work orders/work order types in bulk (can currently only cancel all physical item requests on a set of items in bulk). This would improve versatility and flexibility.

Realise this in not a single enhancement, but no single enhancement will make that much difference. The whole work order system needs to be looked at start-to-finish for real-world usability.

At University of Tennessee we have found we are often waiting on lengthy system jobs to process before manually ran jobs are completed. It would be nice if this page had a built in auto-refresh to reload job percentage completion. It is rather tedious to repetitively click the refresh button to see if a job has began or made any substantial progress. If possible the button should be able to be clicked for instant refreshes but it should also refresh automatically in a timely matter. I believe increments of thirty seconds would be favorable or up to a minute. Thank you for considering this idea!

When providing access to electronic resources from the NZ, resources are made "available for" member institutions and if applicable a proxy is set, meaning the institution's default proxy. However, these institutions may themselves be providing distributed access to e-resources via network inventory groups using different proxy integration profiles (such as different colleges using a single Alma institution, with inventory management groups mapped to campuses). In this case it is not possible for the member institution to use NZ e-resources since the proxy might not work for one or another campus, or one campus in the institution might have access and another might not. Perhaps institution-level inventory management could be visible to be used in the NZ inventory management groups; or perhaps there could be a configuration on the institution end that could connect the incoming NZ resources to the correct institution-level inventory management groups as needed.

Since some institutions have buildings with perpetual restricted access, we have some AFN fulfillment network member libraries that are willing to send their materials to another AFN member library for pick-up, but, for all functional purposes, they are closed to the public. They don't want patrons from the other AFN institutions to visit their library in person, and thus, don't want patrons from another AFN institution to select their library as a pick-up location.

This need has been heightened during the pandemic, with more institutions closed to the public.

We know that turning off all circ desk hold shelves will fully remove an institution from the list of pick-up locations visible in Primo VE; however, if an institution is allowing local requesting for their own patrons (including curbside delivery or for USPS mail delivery), then they need to have the hold shelf enabled.

We need a setting that would allow Institution A to lend/renew/borrow/request/fulfill-requests for Institution B, without allowing Institution B's users to select Institution A as a pick-up location.

Also, if Institution A will lend material to a patron from Institution B, we also need a way to prevent a patron from selecting Institution C as a pick-up location, if Institution C is not open to the public.

The functionality would need to be consistent for the patron for both local and AFN requesting, because it is difficult to teach patrons contingencies.

We have been informed by Ex Libris that when a User Record is updated, either with an API or via the Alma interface, then those fields updated will not be updated with the daily SIS feed. They are considered "manual" changes and are therefore, locked. Now, in the history tab of User Records, you can see the changes made and by whom, but we have been told this information is not available in Analytics and the only way to know who has these locked fields is as we come across them. There is no way currently to systematically pull these records. This is a problem for us - a rather significant problem.