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.

In Primo VE, only one of “vocabulary” is available - “Library of Congress Subject Headings.” The choice to use this “vocabulary” is automatically made for you when you choose “Browse by Library of Congress Subject.” The index “Library of Congress name authority records for 651” is not available through this search as it is through the Metadata Editor via Alma. Thus, many, many LC subject headings cannot actually be browsed in Primo VE. Example, you can find NO headings beginning with “Colombia – Commerce,” because there is no LC subject authority for “Colombia – Commerce” or for any further subdivision of that heading. You CANNOT find the heading “Colombia – Commerce – History” by browse in Primo. Browse by subject gives incomplete results - nearly half the records are not discoverable using this method. Many researchers use this method to find their materials.

Create Discovery Manager roles and give customers the possibility to assign Discovery roles to colleagues who are in charge of specific content updates in the front end (notably Tag management, Resource Recommender management, Primo Central Index activations/deactivations) and who are not necessarily Primo administrators. For more flexibility and granularity, different roles (or parameters to add?) should be created. For example, a staff user in charge of Resource Recommender management should not necessarily have access to PCI activations.

Subject and reference librarians could directly work in Alma in order to keep recommended resources, tags and PCI collections updated; tasks where traditional Primo administrator skills are not required. Currently, a single 'Discovery – Admin’ role concentrates too many responsibilities and functionalities.

It would be useful if item policy could be configured as a field to display in either the brief or full item display. Currently, the loanable indicator is defined by the fulfillment terms of use, which is dependent on users signing in in order for Primo to calculate the loan policy specifically for that user.

Having the option to display the item policy from Alma as a field in Primo would be beneficial as this does not change dependent on the user type or fulfillment rules. It would also provide more information to users irrespective of whether they are able to sign into Primo (e.g. users not affiliated to the institution will be unable to sign in) and makes it clearer and easier for staff to explain to customers why a particular item can/cannot be borrowed.

Consortium partner library's e-resource coverage and public notes should be displayed in Primo VE.

When searching Primo VE in consortium environment with Search Profile "DiscoveryNetwork", coverage of e-resource licensed by the consortium partner library (not by the consortium) is not displayed. Only bib record (in NZ) is displayed.

Currently, no information about e-resource holdings of consortium partner library is displayed and users will not be able to notice that the partner library subscribed to this e-journal. If they noticed, they could access to this e-journal as walk-in users visiting the partner library or request copies of articles through Interlibrary Loan.

Thank you.

Las portadas de Primo se intentan extraer desde el servicio de Syndetics y Google, si el servicio de Syndetics tiene una portada disponible se muestra esta y no la de Google. Por este motivo, por ejemplo, en alma se visualiza una portada de Google y en Primo una de Syndetics.

Primo VE no tiene la opción de desactivar o cambiar la prioridad de las portadas, por lo que para solucionar este problema se necesitaría que se pueda activar o desactivar la prioridad de las portadas.

Esperamos que esta idea resulte de interés a todos los usuarios de PRIMO VE y que contribuyan con sus votos a solucionar este inconveniente en la visualización de las portadas.

Primo VE is configured to map 6XX $v form subdivisions to a separate display field, breaking the subject string. In some cases, the form subdivision is plucked out of the 6XX, leaving the surrounding string incomplete. For example:

600 10 $aO'Keeffe, Georgia, $d1887-1986 $vExhibitions
displays in Primo VE as:

Subject O'Keeffe, Georgia, 1887-1986

Genre Exhibitions

651 #0 $aRome (Italy) $vMaps $vEarly works to 1800
displays in Primo VE as:

Subject Rome (Italy)

Genre Maps
Early works to 1800

And so on, for all 6XX $v form subdivisions. This cannot be reconfigured. Additionally, each occurrence of the form subdivision is displayed as a separate genre. An exhibition catalog with three artists appearing in 6XX fields would result in three genre term displays, all saying "Exhibitions".

To preserve our subject string with form subdivisions intact, we were advised to consider adding a 9XX with the field as we want it to display and labeling that as Subject in Primo VE.This adds steps to cataloger workflow and generates unnecessary data in the records.

This display feature should be reconsidered. Whether or not to split $v form subdivisions should at least be configurable by libraries.

When users request items with multiple volumes in the resource sharing form (NERS Enhancement - Request ID #4856), they can select a specific volume from the pull down list, also freely enter the volume information in the box. Errors of manual input may lead to in inefficient or failure of handling the requests, e.g. user input “1” in the text box instead of selecting “v.1” from the list, the request can be created successfully, but the description cannot be shown in “Borrowing Requests” of Borrowing Library or “Pick from the shelf” of Lending Library, the libraries need to spend extra time to check with each other and the user to confirm which volume was requested. It is advisable to block the free text input function and force user to select volume from a pull down list.