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.

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.

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.

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.

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 setting recall period on a fulfillment loan to "No recall due date", the original due date is kept, while renewal of the recalled loan is blocked.

For some reason, a different logic is applied to lending requests. Setting "No recall due date" as the recall period policy for lending requests, results in the due date being set to the date of the recall. The result is unpredictability for the borrower.

We propose that that these two very similar workflows are better alligned and that setting "no recall period" for recall should result in no change to the due date on a recalled lending request.

Audun Skorstad
Unit – The Norwegian Directorate for ICT and Joint Services in Higher Education and Research

In August 2018 Release we got a solution for the original idea, which made things worse for us. Previously the default for the reading room was set to "Final" check in. The original idea suggested to change this to "Not Final" to help avoid a scenario where for example resource sharing items are returned accidenty to their home campus when users are not finished with them.
As of August 2018 Alma remembers the last selected choice and keeps it for the next action ("sticky approach"). Since eventually every book loaned in the reading room has to be returned "final", now staff has to check each time, whether the last selected choice is the correct one also for the next return action, which is worse than the original situation.
Two cases have already been opened on this problem (#00500765 and #00583992), but support wants us to open again a new idea to finally get what we need:
we need the default to be "Not Final".
Alternatively, the default could be configurable by the library (useful only for libraries that never work with "Not Final" returns: they could set the default to "Final").

The current implementation of exclude process types from publishing has the side-effect, that a holdings record gets automatically suppressed as well if it only contains items which get suppressed based on the exclude from process types configuration.
E.g. if you have process type=acquisition, material type=issue, exclude=true all holdings which happen to only have items with material type issue in process type acquisition are suppressed no matter what. This is bad in itself, since it precludes the possibility of offering additional information to our users via the 866 field.
What makes things worse is that the bib record gets suppressed as well if the automatically suppressed holdings record happens to be the only one for the title and if you have the flag suppress bib with suppressed holdings set to true.
We understand that the current behaviour may be desirable to some, for us it necessitates weird workarounds including dummy holdings / dummy items. So we would urge ExLibris to consider making the suppression of holdings which virtually end up with no items an optional thing.
After all for regular holdings with no items we have a choice whether we want these suppressed or not. For exclude process types from publishing ExLibris made some assumption regarding the correct behaviour which for us simply don't apply.

Oliver Lehner
TU Wien library

My libraries circulate various pieces of equipment from microphones, to musical instruments, to 3D printers, to lockers, and the current physical material type table does not suffice without adding a slew of item policies or location codes, which is messy and makes the resulting analytics more painful than it should be.

Ex Libris support states that "The [physical material type] codes cannot be changed, because Development needs them for statistics across libraries." However individual libraries will have items that they need to distinguish between either for fulfillment rule purposes or our own statistics.

I would like there to be about 15 generic material types added to this table that will allow libraries a bit of flexibility in dealing with this category. Similar to how Primo has blank PNX fields that can be used to create additional facets, etc. that best fit the needs of the library and its users.