Automatic processes in Alma make library staff save time and efforts, but also significantly reduce human interactions with patrons (very few emails are personally sent by librarians to patrons). Lots of Alma letters sent to patrons are nameless and only signed by generic service names like "Acquisitions Department", "Circulation Desk", "Library ABC" etc. (see @@department@@ in the Labels). Some staff members suffer from this dehumanization in the processes.

We want to give a name and a face to a request when patrons get notified and would like to enrich some Alma letters with the name of the librarian who took care of the requests and add a line like for example "You have been served by: Jane Smith". Behind the librarian's name in the letter, the customer could create a link to the librarian's webpage, LibGuides profile pages, the University directory, etc. with the XSL template.

For at least the last staff member who worked on the requests (item hold at the circ desk, digital material sent, item received/activated...), please add the following staff User information:
- First name
- Middle name
- Last name
- Preferred middle name
- Preferred first name
- Preferred last name
- Primary identifier
- Job category
- Job description
- Website URL
in the XML of the following Alma letters:
- Document Delivery Notification Letter
- Ful Cancel Request Letter
- Ful Digitization Notification Item Letter
- Ful Personal Delivery Letter
- Interested In Letter
- On Hold Shelf Letter
- Purchase Request Status Letter

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.

When running a shelf report for a set or call number range we want to know if any items are misshelved in the sense that they are not in the right call number order. As far as we can tell this is not possible but is an essential part of our inventory checking. For example, if we are running a shelf report for all items in our early childhood education collection we want to be able to determine if items within the collection are shelved in the wrong place according to their call number so that we can go to the shelves with a list and put them in their correct call number order.

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.

It's possible to add notes to user records in batch using the "Update/Notify Users" job on a set of users. It would be helpful if we could also batch delete notes on user records.

There are occasions when we have subsets of users who receive special permissions to check out subsets of materials (e.g. students in a specific class who are the only people allowed to use specific equipment or reserve items, collections/materials where we require a signed agreement on file from the user to allow access). In these situations, we add notes to the user record to indicate whether a specific user may use a specific physical resource during a set period of time, such as an academic term. We would like to be able to delete these notes in batch, rather than having to manually edit individual user records-- of which there may be several hundred-- to remove the note that is no longer applicable.

Ideally, the job would allow operators to delete only those user notes that contain text specified by the operator. (e.g. Delete user notes that contain the phrase "Fall 2016" or delete user notes that contain the word "approved")

We encounter a lack of important functionality to efficiently follow-up on In transit requests (physical item requests to another pick-up location). We would like the functionality to be extended with the following additional features:
1. A patron facing letter when the requested item is placed “in transit” by the owning library, so that the patron is better informed of the status of his request.
 We want to create a situation that once a requested item is being transported, there is in fact no way back and a fee needs to paid.
2. To make it impossible for patrons to cancel their request in Primo once the requested item is already in transit or on the hold shelf in the pick-up location.
 We need a granular setup config to define the end user cancellation option in Primo based upon the status of the request.
3. A letter to the owning library when a patron is cancelling his request in Primo, so that the owning library might avoid sending items that have already been cancelled.
 Context: multiple different libraries within 1 institution, and some of these libraries handle dozens of request per day based upon the request slip. This means:
o It’s too time consuming to check the expired hold shelf for all items which are possibly cancelled…
o A cc or bcc added to the cancellation letter is not an option, because this is an institutional letter and cancellation request letters will come in from multiple libraries… The ‘alert’ / letter needs to be owning library specific!

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.

The configurable blocked actions for user blocks in Alma are:
01 – loan
02 – loan, renew
03 – loan, renew, hold

It is therefore possible to configure that blocked users are not allowed to place requests at all.

We propose a distinction between the different request types in blocked actions.

Blocked users should be able to place hold requests, as it can be checked at the latest at the time of loaning whether there is a block, and users then have to take care of the unblocking (e.g. by paying fees) in order to be able to loan the item.
Document delivery, on the other hand, would like to prevent blocked users from placing digitization requests, since there is no check for a block before the scans are delivered and therefore the service can be used permanently without staff and users being notified about the block.

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.

Change "Title Starts With" search in Advanced Search

There are situations when it's easier or more efficient to search by the beginning of the title. However, the “Title Starts With:” search in Advanced Search in Alma requires the user to know whether the title begins with an article (A, An, The) or not, and if so, which article it begins with. So users are expected to remember if a title begins with "A", "The", or no initial article in order to perform the search successfully. Why not just return both results, and let the user decide, instead of forcing them to remember the article?

This case is only about the Advanced search in Alma, not Primo. As such, it would never be employed by end users, only library staff, who are guided by ALA filing rules, the professional standard of which is to ignore initial articles in filing/searching/not index it in cataloging--and so would miss a lot of titles using this search.

Currently, the only way that a “Title Starts With” search which omits the initial article would work is if the record includes a 246 field for a variant title, without the initial article, which is not required by the AACR/RDA standard rules for description. The other primary cataloging standard, MARC format, allows catalogers to implement this via the 245 second indicator (number of non-filing characters). The Alma “Title starts with” search disregards these standards, in effect invalidating a large number of correctly cataloged records.

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.