When using the Restore change type under Change item information, the only change made is toggling the "item is in temporary location" back to NO. Any values filled in for temporary library, temporary location, temporary item policy, temporary call number, etc. remain. Restore should clear those fields, or allow operators to keep those fields by unchecking a box that would be checked by default.

If the item has been scanned to have an item policy for special circ rules, that information remains in the record when it is restored, even though that information is not applied. If the item is given another temporary change that doesn't require a special item policy the previous item policy will be applied when it is moved to a temporary location. See attached file for an example, and desired option to clear all temporary info.

This was also suggested in 2017 NERS as Idea 5111: Remove Temporary Item Information during "Restore" Currently, temporary item information is not wiped out when a temporarily moved item is "restored" either via a staff process or expiration of the temporary move date. The info is confusing and can cause issues with Analytics, Manage Sets, and future temporary moves on the item.

See also the idea relating to removing temporary item information: https://ideas.exlibrisgroup.com/forums/308173-alma/suggestions/11012787-remove-temporary-location-not-just-change-indicat

Making testing and training in an Alma Standard Sandbox based on Ex Libris provided configuration is very difficult since this configuration may be very different from the one in the customer's production environment.

Currently Ex Libris is offering two types of Sandboxes for Alma:
(1) "Standard" - by default included in Alma subscription pricing. This sandbox contains Ex Libris provided data and configuration
(2) "Premium" – for addition subscription fee – this sandbox includes a full copy of the customer's data and configuration

Refresh of the Alma sandbox environment is possible up to once a quarter, upon request. In the case of a Premium Sandbox, Ex Libris updates the customer’s Premium Sandbox with the most recent data and configuration copied from the production environment. In the case of Standard Sandbox, Ex Libris resets the Sandbox data and configuration to the original copy.

We would like Ex Libris to propose an improved Standard Sandbox so that customers can export the configuration from the production environment with a job in order to import it in the Standard Sandbox. This Standard Sandbox would still contain Ex Libris provided data, only configuration would be copied from prod to sandbox. A Standard sandbox containing the customer's configuration would be very useful for staff training, testing of setup scenarios, new enhancements, integration with other systems, etc. This service is already proposed for Primo!

As someone who manages serial subscriptions, I would like the ability to choose the quantity of predictions I create for any given holdings record. This would allow for quicker navigation of list of items, and reduce the number of inaccurate predictions.

It is not always desired to predict an entire year’s worth of predictions (which currently is the only option). Depending on the publishing frequency and the number of copies of a subscription, we can have 11 pages of predictions in a list of items, in addition to the received items. This greatly increases the amount of clicking needed at times to find the item you are looking for. Also, due to variations in publishing schedules and the general inconsistent nature of periodicals, creating weekly predictions a year in advance often results in inaccurate predictions which will need to be modified later.

Currently the "ignorelenderduedate" setting in the Alma Customer Parameters Mapping Table is a global setting; it applies to all resource sharing partners. This is problematic for consortia who have resource sharing partners for consortia members, as well as a resource sharing partner for ILLiad.

Setting "ignorelenderduedate" to "true" works for our consortia resource sharing standard checkout, but ILLiad due dates must be entered manually.
Setting "ignorelenderduedate" to "false" works for the ILLiad lender due date, but then consortia due dates must be entered manually.
If "ignorelenderduedate" could be configured separately, for different types of resource sharing partners, this would allow a more seamless ILLiad to Alma integration.

Alma authority control does not handle cases where the bib heading is linked to an authority via a cross-reference, but the preferred and non-preferred terms are in different fields, e.g. preferred term is in authority field 130 and cross-reference in authority is in 410.

Alma should be able to handle this scenario. Currently when the bib heading matches the authority cross-reference, Alma won't correct these and instead puts them on this report: Preferred Term Correction - Bib Heading found no authorized term.

Example bib heading that Alma won't correct:

110/2_ $$a Allied and Associated Powers (1914-1920). $$t Treaties, etc. $$g Germany, $$d 1919 June 28.

The authority record that this heading links to (via its cross-reference)

130/0 $$a Treaty of Versailles $$d (1919 June 28)
410/2$$a Allied and Associated Powers (1914-1920). $$t Treaties, etc. $$g Germany, $$d 1919 June 28

The bib heading in 110 links to the authority via the cross-reference in the 410, but because the preferred term in the authority is in 130 (and not 110), Alma will not flip the heading.

From time to time, a vendor interface goes down temporarily. While we follow the access issue up with the vendor, we add a public note for our students and staff indicating that the interface is temporarily down. The issue is that often we have many electronic collections with the same interface, and therefore must add a public note to each and every electronic collection that uses the affected interface, and then remove all of the notes once access is restored.

Since all of these electronic collections link back to a single interface, it would be great if there were a field in the interface screen to add a public note about temporary interface unavailability that would appear in the discovery layer for all eresources (portfolios) in the electronic collections linked to that interface.

This would improve the process by significantly reducing the time it takes to add/remove public notes to multiple electronic collections - and also reduce human errors when a public note for a particular electronic collection is missed.

Collaborative collecting agreements are becoming increasingly critical for libraries in managing collections and access across institutions. Formal agreements require libraries to commit to hold specific items. Currently, there is no way to mark this in records unless in free text notes, and no system checks in place for items to prevent accidental weeding of items that libraries have committed to retain. This idea outlines system functionality to ensure that libraries can safely manage committed collections.

• Two new fields in Alma Items: a Committed to Retain check box and a Retention note free text field (minimum of 200 characters)

• A system check that does not allow withdraw (delete) of items in batch, via api, or via the user interface for items with the Committed to Retain toggle set to yes, but instead presents an error noting that the item is Committed to Retain.

• Ability to update these fields manually through the user interface, update in batch via inventory batch job, and update via the item API

• Addition of the Committed to Retain value and Retention note to analytics to allow for collection analysis

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.

Working with purchase orders and invoices requires frequent switching between a purchase order and invoices attached to it. Under the tab Invoice lines in a purchase order Invoice Numbers are listed to the left. On the right side there is a View button, which gives some basic information about the invoice.
In order to view payment date, cheque number, view attached invoice, view other purchase orders associated with this invoice, one must copy the invoice number, then go to Invoices in Open Search Menu, paste the invoice number and then access the invoice record that way.
To directly access invoice records through hyperlinked invoice numbers in PO would save time and make work more efficient.

If this doesn't work, then to access the entire invoice under the View button would be helpful, as well.

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 (enablerequestduringloanfordifferentpolicy 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/KnowledgeArticles/ConfiguringAlmatoAllowMultipleRequestsonA_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

A new multi-selection field, Purchase Request Library, was added to the User Details page with the June 2018 release. If one or more libraries are defined for a user, the user may create purchase requests only for the listed libraries. If no libraries are defined, the user may create a purchase request for any library.

But managing Purchase Request Libraries in user records can only be done record per record; there is no possibility for batch processes.

Currently, there is no option:
- to add or remove a Purchase Request Library with the Update/Notify Users job;
- to add or remove a Purchase Request Library with an API;
- to add or remove a Purchase Request Library with a SIS Integration Profile;
- to retrieve in Alma Analytics existing Purchase Request Libraries in user records or to find user records that have no Purchase Request Library.

We would appreciate a lot a more efficient Purchase Request Library management that would be integrated with the existing tools (Analytics, SIS, job, API).