There is no easy solution in Alma FF to indicate that an item has been consulted in the library and that it can be reshelved.

When items are placed on the hold shelf and are briefly consulted in the library, there is no easy way to directly reshelve them in Alma FF. The workarounds are far from ideal and are very labour-intensive when facing a large amount of physical requests: cancel the request (but this is not correct and influences our request statistics) and reshelve via the expired hold shelf, update the expiry date to yesterday (but this requires a lot of clicks) or wait until the item automatically appears on the expired hold shelf and reshelve from there. With this last option there is too much time between the moment of consultation and the moment of reshelving, which makes that items are not available on shelf or for request for a too long time period. It also makes that new features like the hold shelf reminder letter cannot be set up (because patrons could receive a reminder when they already consulted the item).
Possible solutions are: for an item that is scanned in via ‘return items’ the underlying request will disappear and the item will be reshelved automatically. A button ‘consulted’ (like there is a button ‘cancel’) which immediately reshelves the book when you handle a request is another – less preferable – option.

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 an Automated Fulfillment network allows for their patrons to pick up materials at any Institution in the AFN, it is possible for a patron to pick up their item at a third institution, that is neither the patron's home library, nor the item's home library.

With how Alma currently manages Linked Users, and with the fields available for display on the Active and Expired hold shelf screens, library staff at that third (pick-up only) institution are unable to determine which institution the patron is from.

This is because:

Since the patron is not a local patron to the pick-up institution, and the item was not from the pick-up institution, the patron's linked user record is not automatically saved to the pick-up institution's Alma instance.

This means that the Requester ID that shows when the item is scanned in for hold is not searchable (that requester ID is only searchable at the item's home library), and, without knowing the patron's home library when the AFN is set up for staff to select the patron's home affiliation (because patron identifiers are not unique across the consortium), their name is not searchable either.

We realize the patron would, in theory, receive an email letting them know the item was ready for pick-up from the shelf and would bring their ID with them when they came to pick up the item, but, if the library wanted to contact the patron for some reason, we don't know how they would do that as we don't know how to help them retrieve the patron's record in fulfillment.

Thanks!
Debbie

At the moment Alma only sends one claim request to the vendor. If the ordered item is still not received, staff need to follow up and re-claim manually; usually a number of times.

We would like to see claim cycle functionality in Alma so that we can configure follow-up claims based on a set interval per vendor, as well as a maximum number of claims to be sent before the order is automatically cancelled and the vendor automatically notified. It would also be useful to be able to see the history of claims for an order, and be able to report on this for vendor performance monitoring.

Currently, after running a normalization rule on a set of bib records, the bib records display the 5XX fields out of order, e.g. 500, 546, 506 etc. This occurs even after running the CnmarcBibReSequenceTask as fields between 500 and 899 are not sorted, or sorted only by hundreds (this was the information given to us by a member of staff when we reported the issue on the ExLibris Customer Portal).

Having all fields in the correct order would ease any future cataloguing needed on these records, or when staff members view the record for work purposes.

I've attached an example screenshot.

Currently the only way to use records from NZ in an IZ is to search them in the NZ and perform an action like "order" or "link" on every single record one by one. There are, however, situations where an IZ wants to use a bulk of records. For this purpose we need a possibility to link records in bulk and create inventory for the linked records.

We imagine a linking job that takes as an input a logical or itemized set of records saved from a search in the NZ. The linking job can create physical and electronic (and digital) inventory, similar to current import profiles. The inventory operations for electronic inventory should include an option to specify the desired action if the record and a portfolio exist already in the IZ, out of the following choices:

• Add new portfolio.


• Update portfolio information (the URL).


• Don't do anything.

Use case:
The NZ loads monthly updates from e-book vendors where the IZs have purchased different packages. The workflows for group inventory aren't applicable here because the NZ doesn't possess the necessary information for determining who has rights to which portfolio. OAI is no option because this currently creates duplicate portfolios each time a record gets updated in the NZ. The workarounds currently in place involve sending files back and forth which is error prone and not very efficient.

Ideally, Alma should be able to display ALL unique variant coverage statements when showing a collapsed menu.

If a library uses the Display Logic rules to for example show Proquest as an option only once in a services menu, this works very well where a journal may be in 12 Proquest databases with the same coverage.

However, when the coverage varies significantly between these databases, Alma uresolver will still just show one of the coverage statements and a user will only see a subset of holdings and believe this is all the library has. (eg Nursing standard in Proquest is a good example in some it is 1998-2013 and others is 2015 +, )

The most obvious case is when using the A-Z list or a general Primo search to find a journal title.

In SFX it is possible to add a year or source parameter to the display logic rule so that the collapse display logic only applies when the user specifies a date or when the open url does not come from the A-Z list. This means that a user wanting to use Primo or the A-Z to see ALL date holdings of a given serial title could see all possible links with their coverage statements, not just one statement per provider.

It would be better if the collapsed menu could be preserved and all the unique holding statements were shown, however, the SFX logic of conditionally showing all links is preferable to the current Alma behaviour.

It would be exceptionally helpful to be able to run Analytics reports on all areas of Alma Configuration.

It should be possible both for each individual library to run the reports on their own behalf, AND for libraries belong to a consortium, possible for consortial staff to run the reports across all institution zones simultaneously for comparison between member IZs.

Use cases:
1) Reviewing a spreadsheet containing all of the settings in a configuration area makes settings review easier, and reduces errors. Needing to click between screens and take screenshot to compare settings is cumbersome, and leads to mistakes or unintended differences between settings. It is also easier to review many settings in comparison to each other (example, Fulfillment TOU and Rules), and it is easier to discuss the settings with colleagues through a report format.

2) Since Alma does not maintain an internal change log to configuration changes for most settings, it is possible that library staff may accidentally change configuration and be unable to recover what the settings were prior to the change. The ability to run reports provides libraries with the opportunity to snapshot their settings, in case edits occur that need to be reverted.

3) When libraries are in a consortium, that consortium may have consortial configuration settings/policies that each library should follow. Without the ability to run reports on Configuration settings, consortial staff must log in to each member's institution zones individually, and review each setting manually. This is inefficient, leads to the potential for error, and can impact the patron's experiences. This also prevents consortial staff from being able to provide reports that allow member institutions to compare their settings to the settings of other member institutions for baselining.

We have been using Voyager since 2002, and have had the ability to report on Voyager System Administration settings. I have found those reports invaluable in my time working at the consortium, and would appreciate the same access in Alma/Primo VE configuration.