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.

We would like to have the possibility to include access information in the data that are published from Alma to Primo for Alma-D records (per representation).
Use case:
At this moment, we make the digitized content of all institutions searchable in the views of all institutions of the network.
This is can be very useful for items that are freely available, including digitized heritage.
However, it is inconvenient and confusing for items with restricted access, when the content can only be viewed by users of the institution.
Yet the availability indication for these items is "Online access", because we cannot make the difference between public and restricted items as this information is not published to Primo.

We would like to make the freely available digital materials searchable in all views of the network but items with restricted access only within the view of the institution.
If the information about the restricted access is in the published XML, we can use this in the normalization rules to assign the relevant search scopes.

Because all norm rules can be edited by all staff with cataloger roles, there is great room for erroneous changes for rules that are applied to batch jobs. For example, the norm rule that is applied to records being brought in from Z39.50 targets can be edited by any staff member. A single error in the rule can break the z39.50 import process for all staff until the source of the error is identified. Likewise, if we have a rule applied to import profiles and a staff member inadvertently changes it and we load 50,000 records, that could cause huge data corruption. There needs to be a way to secure a norm rule to administrators such that normal staff with cataloger roles cannot change them.

For those of us working with continuing resources:

When viewing a list of physical items, the sort routine defaults to Library/Location. The items do not appear in any particular order when the results are loaded. Often I change the sort routine to Description or Receiving Date to view the most recent serial items and order them chronologically for viewing.

It would be nice if the sort routine "sticks" so that every time I open a list of items, the sort mechanism will stay on Description (not default back to Library/Location)

This would be especially helpful when managing items in the Receiving module "Received Items List," as we constantly must sort by Description to make sure no serial issues have been missed, and that the most recent issue has been received.

This is very helpful when checking PO lines in the Claims list. From the PO line details page, I click under Ordered Items>View Items. The List of Items sort routine often "sticks" here so that every time I View Items, they are automatically sorted by my previous choice (Description, Receiving Date, etc). This is the only instance I have seen the sort routine stick!

Please, Alma, remember my sorting preferences!

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

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.

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

When a 655 field is coded for LCSH and matches a non-preferred term in LCGFT, Alma flips the heading to the preferred LCGFT term but does not update the coding (it should change the 2nd ind to 7 and add $2 lcgft).

The problem is limited to cases where:

A bib heading 655/_0 matches a non-preferred term in an LCGFT authority

What happens is:

The PTC job flips the heading to the LCGFT preferred form, but it does not change the 2nd-indicator from 0 to 7, and does not add $2lcgft

What is not a problem:

655/_0 headings that already match preferred LCSH/LCGFT form
655/_7, $2 lcgft (these get controlled appropriately)
655/_7, $2 fast (these get controlled appropriately)
655/_7, $2 any other vocab (these do not get controlled)


Example of the bug:

Before: 655/_0 $a Dissertations, Academic
After: 655/_0 $a Academic theses.

The National Library of New Zealand (NLNZ) is ordering and receiving an increasing amount of born digital material, particularly through Legal Deposit. These publications are collected as individual monograph publications and serial issues, not as part of an aggregation or domain/website harvesting, for the purposes of long term access and preservation in our Heritage Collections. They are publications in their own right, not digitised version of print holdings. Alma’s Acquisitions workflows do not currently have any options to allow for steps that are specific to receiving born digital material.

Our current workflow involves the creation of Vendor records and POLs using a physical workflow (Print Book – One Time or Print Journal – Subscription). This allows us to manage vendor information, orders, claims and occasionally invoices. Born digital material is distinguished by a specific location and material type. We receive each born digital item in the physical workflow and then ingest it into our repository (Rosetta). There is then a synchronisation between systems that creates the digital rep and updates the label information. This means, particularly for serial issues, that we are duplicating data in the receiving (Alma) and ingest (Rosetta). The physical location we use for all born digital material is supressed so that what shows in Primo is the digital rep, not the physical item.

What we would like to see is a suite of born digital options within acquisitions in the same way as there are currently separate options for electronic material. This would include functionality for additional information such as access levels, in vendor management, orders, claims, invoices etc.. Our thinking is that the critical difference in a born digital workflow is functionality where item receipt is triggered by the creation of the digital rep either in Alma or through syncing with an external repository. This would remove the need to enter data twice and would also allow us to manage a claims workflow effectively.

We have detected this case that we consider is an incorrect behavior of Alma.

When a purchase request is generated, a non-visible bibliographic record is created. The problem is that if a second purchase request for the same document is generated, Alma automatically makes the bibliographic record visible, even though we still do not have copies of it. Therefore this record appears visible in Polibuscador but without funds.

We request that the bibliographic record should only be visible when the issue or copies are available to the user, meanwhile, even if more than one purchase request has been made, it should remain suppressed.

Currently, it’s impossible to tell how ‘Digital’ and ‘Other’ inventory may be configured in the Inventory section of a citation. The green indicator shows the inventory exists but not whether it has been used for the citation.

Digital example:
You can’t see whether a digital representation has been selected via the ‘Manage Digital Representations’ option or whether a representation is Active or Inactive. The green indicator stays green even if the representation is Inactive or if it hasn’t been selected via Manage Digital Representations.

Other example:
You can’t see whether the Link Resolver has been disabled via Edit > Citation Parameters > Disable Resolving. The green indicator stays green even when you disable resolving.

As a result, when a citation isn’t behaving as expected in Leganto it’s time consuming to identify the cause. If there were enhanced indicators within the Inventory section, you would be able to tell at a glance what the problem may be (e.g. the representation has been set to Inactive, it hasn’t been selected via ‘Manage Digital Representations’ or link resolving has been disabled).